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

From: [email-masked]
Date: Mon, 23 Jun 2008 15:26:28 +0100

I've just submitted draft-bellis-send-n-02 and it's available now online 
at http://tools.ietf.org/html/draft-bellis-enum-send-n-02

Could those who commented so vigourously on the -00 draft and then failed 
to make any comment at all on -01 please take a look at this one and 
comment now so that we don't have to spend too long over it in Dublin?

The changes over -01 are relatively minor - mostly there were some small 
editorial nits and I've rewritten some of the text to make it a little 
clearer about the possible uses for this data.

thanks,

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: Duane <[email-masked]>
Date: Tue, 24 Jun 2008 06:37:47 +1000

> comment now so that we don't have to spend too long over it in Dublin?

What's there to comment on, the same problem still exists as in 00, you
break wild card records and as such you will get disparity between
countries. You would be much better doing something else that doesn't
break DNS that all countries could use. I still find this a very useful
idea if only it didn't break wild card records.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Tue, 24 Jun 2008 08:45:17 +0100

Duane

I've made specific allowance for an absolute form of the Send-N record 
which *is* compatible with wildcard records.

Ray

---

From: Duane <[email-masked]>
Date: Tue, 24 Jun 2008 19:29:07 +1000

Yes, but it's still possible to break wild cards:

> 7.2.  DNS Wildcards
> 
>    The relative form of these records SHOULD NOT be used with DNS
>    wildcards since DNS wildcards can represent an arbitrary number of
>    labels (or digits, in the ENUM case) and the data in a relative form
>    'Send-N' record is specific to an exact position in the ENUM tree.

and if there is anything I've learnt, when ever you give someone enough
rope they'll surely hang themselves sooner rather than later.

I fail to see why your use for DNS should take precedence over existing
DNS types at all, this will only lead to disparity between countries, I
find the idea of databasing this information useful, but don't break
existing systems to achieve it.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Tue, 24 Jun 2008 15:59:06 +0100

> existing systems to achieve it.

My use doesn't take precedence.  If you need to use wildcards, and the 
absolute Send-N form isn't suitable for you, just don't put in any Send-N 
records at all.  They're completely optional.  The need to wildcard can 
take precedence.

There are plenty of cases where bad things are possible through 
misconfiguration of DNS records, and the usual answer is "don't do that". 
I'm struggling to understand why that's not considered a valid answer in 
this case.

For what it's worth, section 5.7 of the Enumservices Guide draft 
specifically requests that Registration documents should identify any 
incompatibilities with wildcard records.  That's an explicit understanding 
that such incompatibilities are possible. 

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jun 2008 11:09:22 -0400

I still have my objection to the basic notion that the base enum query is
the right way to determine how many digits are needed to route.  I think
that information is static, and we need a standardized way to find it out,
and send-n is not the right way to do that.  I think overlapped dialing is
going away, and devices need to be told how many digits to collect before
pressing "SEND" or the equivalent. 

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, June 23, 2008 10:26 AM
> To: [email-masked]
> Subject: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
>

---

From: [email-masked]
Date: Tue, 24 Jun 2008 16:34:24 +0100

"Brian Rosen" <[email-masked]> wrote on 24/06/2008 16:09:22:

> I think overlapped dialing is going away, and devices need to be told 
how
> many digits to collect before pressing "SEND" or the equivalent. 

I disagree.

The particular application where this has real use is standard POTS phones 
sending DTMF into a switch that uses ENUM-like technology to route the 
call onwards.

There's no way to make those current devices do a "send", and there's 
*millions* of them out there.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jun 2008 11:58:46 -0400

The solution to the looking forward problem is easily applied to the looking
backward problem.

If the proxy controlling the dialing for an old device has access to the
same data the new device that is controlling the dialing has, then the
problem is solved.

The send-n solution isn't applicable to a device with a SEND button in a
sensible way.

Brian

> Sent: Tuesday, June 24, 2008 11:34 AM
> To: [email-masked]
> Subject: Re: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
>

---

From: [email-masked]
Date: Tue, 24 Jun 2008 17:10:52 +0100

> same data the new device that is controlling the dialing has, then the

I don't follow your reasoning.  The soft switch I described doesn't have 
internal number length information, it only has a DNS interface to an 
ENUM-like database tree.

This isn't hypothetical, BTW.  It's how the UK's number portability 
solution is expected to work.

> The send-n solution isn't applicable to a device with a SEND button in a

Yes, that's correct.  It's not supposed to be.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jun 2008 12:19:08 -0400

Send-n is not implemented in the enum client.

Implement something else (i.e. a client to another database which has length
information) in the same server.

It's possible that we'll decide the protocol for this new database is DNS.
I have no opinion on that yet.  I have an opinion that we should have a
database with length information that all services, and all devices, can
make use of.  Send-n is too limited, in my opinion.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2008 12:11 PM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: RE: [Enum] Send-N draft: draft-bellis-enum-send-n-02 published
>

---

From: [email-masked]
Date: Tue, 24 Jun 2008 17:39:12 +0100

> Send-n is not implemented in the enum client.

Not in an end-user client, no.
 
> information) in the same server.

When devising this at NICC we did consider several alternatives.

Using NAPTR records in DNS was ultimately chosen for several reasons, the 
most compelling of which is because it's simply optimally efficient if 
you're already doing a DNS lookup for NAPTR records in an ENUM-like tree 
to get back a Send-N record immediately rather than have to issue a second 
lookup request (whether that request be another protocol or a DNS query 
with a different QTYPE).

Granted this isn't faithful to the public ENUM dogma that says that 
lookups should only be done on full numbers.  However this isn't intended 
for public ENUM.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Jun 2008 13:02:13 -0400

In your example, the enum client is in a proxy server.  The proxy server is
trying to route a call.  Your solution is to hit enum with some query (not
clear to me how you decide when to start trying, since you at least need to
decode the country code, and may be decoding more than that).  You then get
back send-n.  That tells you how many digits to get, but it's very likely
that you will have to repeat it i.e., you start with the country code, you
get back the minimum number of digits.  You query again, and you probably
get back the right number.

Worst case is you are really dumb and you send a single digit.  You get back
"send 10" for CC1 or send 1 for nearly every other case.  You then send 2
digits and then you would get some number of digits for a minimal TN in a 2
digit country code, or you would get send 1 (for a 3 digit country code).
For the 3 digit case, you query again with one more digit and you get the
minimum number of digits (as with the second call in the 2 digit CC).  You
query again with that number of digits and you either get an answer or some
more send-n.  This continues, each time you have to query the database.

I claim there is no significant difference between the two solutions for an
overlapped dialing device.  They get to the same result with about the same
amount of effort.  Probably my solution uses more memory, but so what.  I
claim that my solution is much better for a non-overlapped dialing device.

You came here with a problem many of us recognize as a real problem: how
does any entity know how many digits it takes to get a routable TN?  We
agree; that's a problem worth solving.  You have a solution in mind to that
problem.  I'm arguing it's not a good solution for everyone with the
problem.  You seem to agree, but you like your solution for the overlapped
dialing case.  I'm suggesting that we are better off solving this problem
for both overlapped and non-overlapped dialing devices using one mechanism.

Brian

> Sent: Tuesday, June 24, 2008 12:39 PM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 25 Jun 2008 23:07:39 +0100

> sending DTMF into a switch that uses ENUM-like technology to route the

Eh? Why would such a beast need send-n NAPTRs? Where are the  
requirements and how can this WG assess whether send-n meets those  
requirements? I would have assumed switches would have a priori  
knowledge of the prevailing numbering/routing plan irrespective of  
whether they used ENUM-like technology.

---

From: Roy Arends <[email-masked]>
Date: Thu, 26 Jun 2008 11:05:39 +0200

> existing systems to achieve it.

I find the argument of 'X breaking wildcards' ridiculous. There is no  
such thing. If there would be anything breaking wildcards, it would  
have been used and deployed widely already, since wildcards are often  
considered evil.

Also, the concept of wildcards in DNS is often misunderstood. On many  
occasions, the DNSEXT WG were asked to please fix wildcards, as it did  
not behave as expected to those who wanted to use them.

Wildcards are a part of the dns protocol. NAPTR records are used by  
applications that use the DNS protocol. There is no way that  
application use of the DNS can break the underlying DNS protocol.

It is perfectly fine to state that X SHOULD NOT be used with  
wildcards. I would suggest you actually help to find alternative  
language to state that the use of the relative form of send-n NAPTR  
records combined with wildcard domain names is NOT RECOMMENDED as it  
might lead to unexpected behavior.

As for prior art, there are many other examples where use of X and  
wildcards are not recommended. DNAME and wildcard domain names. SRV  
records and wildcard domain names.

As for you 'precedence' statement, I fail to see how you come to the  
conclusion that relative send-n NAPTR RRSets have precedence over  
wildcards. Obviously, quite the reverse has been stated, in that these  
records SHOULD NOT be used with DNS wildcards. (i.e. if you have  
wildcards, you should not use these records). If you'd like to argue  
that this statement is too ambiguous, send Ray text to help him  
disambiguate the statement.

Furthermore, if there is any evidence that an application use of  
existing DNS resource record types breaks Wildcard Domain Names or the  
processing of it, or undermines the DNS protocol, please bring it to  
the DNS Extensions WG.

Thanks,

Roy

---

From: Jim Reid <[email-masked]>
Date: Thu, 26 Jun 2008 10:33:31 +0100

> records and wildcard domain names.

Roy, just because a few specialised RRtypes can't be used with  
wildcards doesn't mean others should follow in that path. Just because  
others are doing something bad/stupid/dangerous can't be an excuse for  
the same behaviour. You wouldn't drink Coors Light (say) simply  
because lots of other people drink that awful liquid, would you? We  
both know why the semantics of DNAME and SRV (not forgetting NS and  
SOA) make wildcarding these RRtypes more than inappropriate. None of  
them have that property because of what's in their RDATA. I am *very*  
uncomfortable that n-send's impact on wildcarding is dependent on the  
record type's RATA and would have hoped you were too.

Even so, I can live with Ray's change of "MUST" to "SHOULD" here. It's  
still very ugly though.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: Roy Arends <[email-masked]>
Date: Thu, 26 Jun 2008 11:42:33 +0200

On Jun 26, 2008, at 11:33 AM, Jim Reid wrote:

> wildcards doesn't mean others should follow in that path. Just  
> because others are doing something bad/stupid/dangerous can't be an  
> excuse for the same behaviour. You wouldn't drink Coors Light (say)  
> simply because lots of other people drink that awful liquid, would  
> you? We both know why the semantics of DNAME and SRV (not forgetting  
> NS and SOA) make wildcarding these RRtypes more than inappropriate.  
> None of them have that property because of what's in their RDATA. I  
> am *very* uncomfortable that n-send's impact on wildcarding is  
> dependent on the record type's RATA and would have hoped you were too.
>
> Even so, I can live with Ray's change of "MUST" to "SHOULD" here.  
> It's still very ugly though.

Jim,

This is the typical dogma I see a lot: "I don't like Coors light,  
Harry doesn't like Coors light, Therefor, I don't want you, nor anyone  
else to drink Coors light."

I'd like us to break these dogma's, and come up with proper technical  
arguments.

Roy

---

From: Jim Reid <[email-masked]>
Date: Thu, 26 Jun 2008 11:06:00 +0100

On 26 Jun 2008, at 10:42, Roy Arends wrote:

> I'd like us to .... come up with proper technical arguments.

OK Roy.

Could the proponents of n-send please explain why the semantics of  
wildcarding have to undergo further complication by making them  
conditional on the RDATA of an existing resource record? Not ony that,  
they're conditional on a subtype of the RDATA. This goes to the core  
of the stability of the DNS protocol. It's incumbent on those  
proposing this change to explain that it won't break anything or  
require yet more corner cases in wildcard handling/processing by  
servers, resolvers and end applications. Saying "we're doing this in  
private between consenting adults" is not an answer.

Saying n-send SHOULD NOT use wildcards is all very well. But what if  
someone does do that? Even behind closed doors? What operational  
impact would that have? What sort of action would those DNS  
implementations need to take? Will it require extra code? If so, where?
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: [email-masked]
Date: Thu, 26 Jun 2008 12:10:54 +0100

> private between consenting adults" is not an answer.

I'm not proposing (IMO) any changes to the semantics of wildcarding. 

The use of Send-N in wildcards neither imposes nor requires any changes in 
wildcard handling in any DNS server, resolver, or application.

> implementations need to take? Will it require extra code? If so, where?

As per the draft, the worst case if someone published a Send-N record in 
an I-ENUM tree that was incorrectly high is that it might result in the 
numbers covered by that record not being reachable.  That's true even if 
wildcards aren't used, and irrespective of whether this is a NAPTR record, 
some other RR-type, or **any** other sort of Send-N database (whether 
real-time or hard-wired).

This *is* a risk, but it's along the same lines as any other 
misconfiguration of DNS data - "don't do it".

The only reason that wildcards are an issue is because a relative-form 
Send-N record in a wildcard could result in the ENUM client repeatedly 
continuing to expect more dialled digits until the 15 digit E.164 maximum 
is reached.  In effect, a relative-form record in a wildcard is 
automatically "incorrectly high".

The only place any code is required is in ENUM clients, but only in those 
that specifically want to support Send-N, such as I-ENUM enabled switches.

As far as any DNS server is concerned, it's just another NAPTR record. 

Ray

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:24:43 +0100

Jim Reid said:
> Eh? Why would such a beast need send-n NAPTRs?

To determine how many digits to collect before querying the database again.
See section 1 of the I-D.

> Where are the  
> requirements?

The requirements are explained in section 1 of the I-D, particularly
paragraphs 2 and 3.

> I would have assumed switches would have a priori  

To the best of my knowledge, *NOBODY* has a priori knowledge of the whole UK
numbering/routeing plan. This explicitly includes the Regulator.

-- 
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: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:33:37 +0100

Jim Reid said:
> conditional on the RDATA of an existing resource record?

They don't. No change to the semantics of wildcarding is being proposed.

> Not ony that,  

If an application is not specifically interpreting SEND-N (and this
includes all DNS servers and anything other than an overlap-dialling
switch), then these records have no effect on that application.

> implementations need to take? Will it require extra code? If so, where?

The DNS implementation? Nothing.

The specific application interpreting SEND-N records needs to take a
teeny-weeny bit of care. A wildcard record like:

    * IN NAPTR ( 100 10 "u" "E2U+pstndata:send-n"
                            "!.*!pstndata:send-n/2!" . )

is in effect an infinite loop: it tells the application to fetch 2 more
digits and then query again, whereupon it hits the same record again
(assuming there isn't an explicit record there as well that overrides it).
The application therefore needs to have some kind of loop detection and
limit, whether testing for wildcard records, putting a limit on the number
of dialled digits, putting a limit on the number of SEND-N records it reads
for a single call attempt, or whatever. [Ray: you could perhaps put in a
usage note to that effect.]

But anyone else reading those records *will not be affected* as far as I
can see.

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 27 Jun 2008 13:40:24 +0100

Hi Clive, folks,
  You combined numbering and routing - do you assert that these are  
identical?

If you imply that the regulator does not know about the current  
service provider
for any given number, they you should say that  - it is not my  
understanding of
the term "number plan" and may not be understood that way by others.

all the best,
  Lawrence

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:43:00 +0100

Duane said:
> break wild card records

I still don't understand what gets "broken".

> and as such you will get disparity between
> countries.

You say that some countries use wildcards. Fine; let them continue to do
so. The UK using SEND-N won't break this, or vice versa.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:45:11 +0100

Brian Rosen said:
> that information is static,

It's not *that* static, particularly in some countries.

> and we need a standardized way to find it out,

Right.

> and send-n is not the right way to do that.

Then what is? Preferably without *adding* to the number of lookups required
when the "standardized method" isn't in place.

> I think overlapped dialing is
> going away,

Why on earth? There are hundreds of millions of devices that do overlapped
dialling, and they aren't going to be replaced any time soon.

> and devices need to be told how many digits to collect before

Where's '"SEND" or the equivalent' on my home phone?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:48:58 +0100

> The solution to the looking forward problem is easily applied to the looking

What is the "solution to the looking forward problem"?

> same data the new device that is controlling the dialing has, then the

What data? The problem is that the devices don't have this data.

> The send-n solution isn't applicable to a device with a SEND button in a

Agreed. A device with a SEND button either gets the right length given to
it *by the user* or it doesn't.

So what?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:52:13 +0100

> It's possible that we'll decide the protocol for this new database is DNS.

And if we do decide this, it ought to minimize the number of DNS lookups.
Which means returning NAPTR records.

> make use of.  Send-n is too limited, in my opinion.

What doesn't it do that your proposed new protocol would do?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 27 Jun 2008 13:57:01 +0100

>  You combined numbering and routing - do you assert that these are  

No. I actually meant "numbering", but I was deliberately copying the
phrasing of the previous message, which said "numbering/routeing".

The "full ENUM records" contain routeing information in some form, but
these records aren't intended to.

> the term "number plan" and may not be understood that way by others.

No, that's not what I mean (though I'm not convinced of that either).

Very simply, there are number blocks where we know the CP they are
assigned to, but we don't know the length of numbers in that block (and,
indeed, different numbers in the block may have different lengths).

However, even if Ofcom's records were perfect, the arrangements are too
complicated to be represented in a simple table *and* change from time to
time.

Given how hard it is to get some overseas operators to even understand that
not all UK numbers begin with 01, any kind of fixed table that has to be
distributed is completely impractical.

---

From: Jim Reid <[email-masked]>
Date: Fri, 27 Jun 2008 13:58:55 +0100

On 27 Jun 2008, at 13:33, Clive D.W. Feather wrote:

> No change to the semantics of wildcarding is being proposed.

Sorry Clive, you're wrong. There are. The draft makes wildcard  
processing conditional on the RDATA that's in one of these nsend  
NAPTRs. This *is* a change in semantics and the consequences of that  
have still to be worked through. You even go on to concede the  
semantics are changed by pointing out a corner case where a badly  
structured nsend NAPTR causes an infinite loop.

Now it's one thing having applications playing in this nsend world  
perform loop detection. [How? And where is this documented?] But are  
there scenarios where name servers, espeically full service resolvers,  
could end up having to do loop detection? Some further analysis is  
required. IMO, the proponents of nsend need to do that work and  
convince this WG and dnsop that there is no impact on either the DNS  
protocol or implementations.

It's all very well for the draft to say nsend SHOULD NOT be used with  
wildcards. But it really has to say something about what happens if/ 
when that advice is not followed.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: [email-masked]
Date: Fri, 27 Jun 2008 14:27:24 +0100

> structured nsend NAPTR causes an infinite loop.

To clarify, it's our belief that the semantics of wildcards w.r.t standard 
DNS clients and servers are not changed by this one iota.

As per my message yesterday, and one of Clive's today, the only thing that 
changes is the ENUM client code, and then only in those clients that need 
to support overlapped-dialing via Send-N.

> perform loop detection. [How? And where is this documented?]

I'll look at including a more detail description of the Send-N algorithm 
than is currently in Section 5.  In practise there wouldn't actually be an 
infinite loop because E.164 numbers can't exceed 15 digits.

> But are there scenarios where name servers, espeically full service 
resolvers, 
> could end up having to do loop detection?

No, there are not, IMO.  I don't believe that I can *prove* that's the 
case, but I know that I cannot think of any such scenario.  Nor can our 
in-house DNS gurus.  If anyone *can* think of an example please let me 
know.

These are *just* RRs after all.  All the DNS server has to do is serve 
them, using the existing rules.

> Some further analysis is required. IMO, the proponents of nsend need
> to do that work and convince this WG and dnsop that there is no impact
> on either the DNS protocol or implementations.

My experts say it doesn't - I'm happy to ask Peter and Rob for second 
opinions.

> when that advice is not followed.

It does - but I'll try and make it clearer.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jun 2008 10:03:56 -0400

Read the thread.

What you want is a dial plan.  Fine, we should standardize a way to get a
dial plan for every TN.  In nearly every case, that comes from the
regulator.  There are conditions where what you get from the regulator is a
dial plan that determines the end of a "prefix" and you have to go somewhere
else to get the rest of the dial plan.  Fine, we can do that.

99% of the telephone numbers in the world have a pretty simple dial plan.
That's the case we should optimize.    

Overlapped dialing decoding is walking through a dial plan.  We should
provide the means to do that.  All of the hundreds of millions of phones you
are talking about work fine without Send-N.  They have the dial plan for the
home country burnt into the switch, and they use a time out for
international numbers.  

There is value in improving the dialing experience of everyone, but not so
much that we need make it really optimal.  You have brought us a problem I
think is worth solving: determining dial plans for international numbers.  I
don't like your solution, but I'm happy to work on the problem.

Brian

> From: Clive D.W. Feather [mailto:[email-masked]]
> Sent: Friday, June 27, 2008 8:45 AM
> To: Brian Rosen
> Cc: [email-masked]; [email-masked]

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 00:04:57 +1000

> I still don't understand what gets "broken".

It gets 'broken' because send-n will interfere with wild card records
because in most case the most specific record should take preference.

> so. The UK using SEND-N won't break this, or vice versa.

Why does such a case need ratification for if there is only going to be
a small subset of private users taking advantage of it?

If there is only going to be private users let them sort it out amongst
themselves as to what they are going to do rather then coming up with
half baked ideas that break existing dns types. If on the other hand
this is supposed to be useful for the wider internet community than some
other method would still be needed not to break dns types, otherwise why
bother with the standardisation process if you already have it stuck in
your head this is the one true way and no one can tell you any differently?

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 00:11:22 +1000

> don't like your solution, but I'm happy to work on the problem.

Pretty sure this has been pointed out before, but their idea also
manages to break ENUM RFCs with respect to sending the complete number,
in most cases maybe they will since as you point out most numbers follow
simple dial plans, however for corner cases they will send repeated
requests.

-- 

Best regards,
 Duane

---

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

> What doesn't it do that your proposed new protocol would do?
It doesn't give you the dial plan.  It tells you how many digits are needed
to be collected until you get to the next step in the dial plan.

We have a language to describe dial plans.  See MGCP or Megaco's digit map.
We don't need to use that language, but it's representative of the kind of
information a dial plan has.  

I want something that determines the shape of the enum tree.  I need that
even before I create the tree.  The authoritative source for the information
is typically the regulator.  Today, it's typically published as a Word
document by the ITU.  I want to set up a mechanism for the regulator, or
someone operating on its behalf, publishes the data that currently is
published in that Word document as a database anyone, including the enum
operator, can use.

The way I want to use the data for a next generation phone is to download
something like the MGCP dial plan when an international number is dialed, so
the user can see/hear/feel, via a GUI, when they have a good number.  I want
to not even send one DNS query to ENUM unless I have a good number.

Brian

---

From: [email-masked]
Date: Fri, 27 Jun 2008 15:18:33 +0100

> That's the case we should optimize. 

I don't believe it's as simple as you say.

The UK dial plan alone contains 1000s of entries.  Germany's is another 
100+.

> are talking about work fine without Send-N.

But those existing phones are connected to switches that *do* use Send-N 
in C7  (which of course is what this is named after).

> They have the dial plan for the home country burnt into the switch, and 
they use
> a time out for international numbers. 

The large number of dial plan entries for the UK means that for some 
number ranges (in particular +44800) they're having to use inter-digit 
timeouts, and they're not happy about it.

The UK carriers are therefore actively trying *not* to have the UK dial 
plan burnt into their switches, and this is the proposed implementation.

> much that we need make it really optimal. 

The carriers consider any use of time outs to be unacceptably sub-optimal. 
 Our proposal avoids them completely.

> You have brought us a problem I

The more the merrier :)

cheers,

Ray

---

From: [email-masked]
Date: Fri, 27 Jun 2008 15:22:51 +0100

> even before I create the tree.

Actually in the UK implementation it's the shape of the tree that 
generates the Send-N data.  The ENUM tree is (de-facto) whatever shape the 
dial plan is.  If the ENUM tree is sparse, that's fine.  The ENUM client 
in the switch will get an NXDOMAIN and give an NU tone.

There's no need (IMO) for it to be the other way around.

> to not even send one DNS query to ENUM unless I have a good number.

This is of primary use for dumb phones (i.e. without GUIs) talking to 
smart switches.

Smart phones don't need Send-N.

Ray

---

From: [email-masked]
Date: Fri, 27 Jun 2008 15:34:48 +0100

> because in most case the most specific record should take preference.

I still don't understand your objection.

If a specific record over-rides a wildcard containing a Send-N record, so 
what?!

That just means that the switch implementing Send-N will keep on asking 
for digits (one at a time) until the full number is found[*]

Can you provide an actual example zone showing how this doesn't work?

Ray

[*] Yes, I know looking up partial numbers breaks Section 2 of RFC3761. 
However IMHO that paragraph is unnecessarily restrictive because nothing 
ever actually breaks if that "rule" is broken.  This is unfortunately a 
necessary step if overlapped dialling is ever to work in I-ENUM.

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 00:37:45 +1000

> Can you provide an actual example zone showing how this doesn't work?

;; QUESTION SECTION:
;9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. IN NAPTR

;; ANSWER SECTION:
9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
"!^\\+44800(.*)$!sip:44800\\[email-masked]!" .
9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
"!^\\+44800(.*)$!sip:44800\\[email-masked]!" .
9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
"!^\\+44800(.*)$!sip:44800\\[email-masked]!" .

As per my last email you are also breaking ENUM RFCs, not just DNS ones.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 00:43:43 +1000

> to not even send one DNS query to ENUM unless I have a good number.

Sounds very BGPish or some other routing protocol, where the routing
information is 'pushed' out to the wider community so everyone gets a
complete view rather than relying on DNS for updates. This way updates
could be pushed out to these smart switches in real time rather than
sending packet after packet to get dribs and drabs of DNS information at
a time. Taking a routing approach seems more logical to me simply
because this would be a lot more efficient lookup, ram is cheap and
processing it locally would certainly reduce load on central systems etc.

-- 

Best regards,
 Duane

---

From: Eleanor McHugh <[email-masked]>
Date: Fri, 27 Jun 2008 15:53:42 +0100

> Which means returning NAPTR records.

It's not entirely obvious that using NAPTR records this way would  
result in any fewer DNS lookups than by providing a new RR type.  
Either way the zone record still needs to be loaded, and with a  
request for NAPTRs the client could in theory get a larger data set  
back which would then need to be processed locally: probably a trivial  
cost, but still a consideration for implementers.

Also in terms of the actual usage, one question does arise: what  
happens if a send-n NAPTR is provisioned as an NTN? Given the  
restriction to digits only beneath .e164.arpa, it's hard to think of a  
use case where that NTN could possibly point to a meaningful target  
without leading outside of the ENUM hierarchy. This then leads me to  
consider an obvious cache poisoning attack where:

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "!.*!pstndata:send-n/=11!" .

is replaced with:

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "" call.capture.arbitrary.tld

or

	IN NAPTR 100 10 "u" "E2U+pstndata:send-n" "" [premium rate  
number].e164.arpa

and the call is funnelled off elsewhere. This is obviously at a  
tangent to the main point of the current discussion, but unless you  
can think of a good NTN use case with send-n they should probably be  
explicitly forbidden.

> What doesn't it do that your proposed new protocol would do?

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.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jun 2008 11:04:59 -0400

1000 entries in a database is laughably small.  Downloading it to a phone as
the country code is dialed is even easy (although I suspect you wouldn't do
that to a wireless phone with current data rates, you might with 4G data
rates).

Here is a more or less concrete proposal:
The regulator publishes, in the existing ITU document, a URI of its current
dial plan.  The URI yields an XML data structure that looks like:
<dial-plan globalprefix="+1">
...
<assignment operator="ATT" use="wireless" prefix="202555" min=4 max=4/>
...
</dial-plan>

The operators do the same with codes that are different min/max in the
regulators data.  So, let's say there was an assignment like
<assignment operator="BT" use="wireline" prefix="456789" min=3 max=7/>

Then BT may have
<dial-plan globalprefix="+444567898">
...
<assignment prefix="123" min=1 max=1>
...
</dial-plan>
Which means that +445678981232 is a good TN.

Now, that's quite verbose.  It would be very simple to turn that data into
an MGCP digitmap, or a Finite State Machine algorithm, or some really
compact binary tree thingy that encoded the same information in far fewer
bits.

I chose the XML because it closely represents the form the data is now
provided.   Any other simple to understand form would be fine.

What is important to me is that it be something the authoritative source of
the data can reasonably publish, and that it work for the cases which are
easy as well as the cases that are hard, using one of my favorite dictums
that "simple things should be simple, complex things should be possible".

Brian

> Sent: Friday, June 27, 2008 10:19 AM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 27 Jun 2008 16:47:23 +0100

Hi Jim, Ray, folks,
(i) Sod. The experiences draft (and 3761bis) talk about non-terminal  
NAPTR loop detection and recovery,
but the loop they describe is inside a single ENUM lookup.

It is NOT the result of an ENUM application doing a "same player play  
again" after a terminal result,
as described for send-n.
=> the text currently in Experiences/3761bis doesn't cover this  
scenario. Nor does it cover an ENUM application looking up a telephone  
number, getting a voice:tel NAPTR back with the same number, and doing  
the lookup again.
You can't legislate for complete stupidity (even in Washington D.C. :).

I don't think that 3761bis is an appropriate place to add such text,  
as there has been no discussion there of individual misbehaving ENUM  
applications. To do so now would be a sisyphean task.

However, in the send-n case, looping/spiralling a sequence of  
individual ENUM lookups seems expected behaviour for the send-n  
application, so it must be covered somewhere.

Might I suggest that the Bellis Enumservice spec MUST document this?

Things to cover in that document include (off the top of my head) are:
in a single send-n number processing call, how long a sequence of ENUM  
lookups is valid
is there ever a reasonable case where two ENUM lookups can be done in  
the same ENUM zone by the same device,
is there a reasonable case where identical ENUM lookups can be done  
for the same ENUM zone by different entities in the routing chain,
...

(ii) Also in the document, it would be good to see an estimate of the  
number of DNS queries made for all send-n number processing calls  
needed to route a number, for a known number plan.
It would also be good to see a listing the assumptions about whether  
this is intended to be done by every local switch, or what, and why it  
would be done, and the implications with some given "erlang-level"  
models for a global system (as that seems to be part of the business  
plan for this scheme), ...

(iii) I recall one of the major reasons why ENUM was intended for  
numbers that were reasonably expected to be complete was to avoid  
hammering the DNS - it will get hammered anyway with the number of  
(PSTN) Busy-Hour Call Attempts worldwide. Thus I'm pretty sure that  
the DNS crowd will need to be convinced that this scheme, apparently  
supporting the majority of "steam phones" out there, will not swamp DNS.

(iv) BTW:
>                            "!.*!pstndata:send-n/2!" . )
I'm sure there's a good reason why the Enumservice is harris about  
apex in Clive's example.

all the best,
   Lawrence

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 27 Jun 2008 17:09:02 +0100

Hi again Ray, folks,
  Let me get this straight - this whole thing is being developed  
because some historical choices by a Regulator in the UK covering  
freephone numbers means that there are numbers in that range with two  
different lengths?
[AFAICT, forget the dialling plan side of things, it's a red herring -  
this is a number plan issue]

The current situation is that Operators have to "do some funky stuff"  
in each switch to handle this historical choice, and I can understand  
why they are unhappy with it. It was brain damaged, it is brain  
damaged, and it needs to be fixed.

However, why on earth should the IETF produce something this  
"interesting" just to deal with UK freephone numbers?
You have already said that the current (PSTN) situation is a mess -  
inter-digit timeouts and all.
This is not an ENUM issue - it's a general issue with that particular  
part of that country's number plan.

all the best,
   Lawrence

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 27 Jun 2008 17:34:40 +0100

Hi again Ray, folks,
Let me get this straight - this whole thing is being developed because  
some historical choices by a Regulator in the UK covering freephone  
numbers means that there are numbers in that range with two different  
lengths?
[AFAICT, forget the dialling plan side of things, it's a red herring -  
this is a number plan issue]

all the best,
  Lawrence

---

From: [email-masked]
Date: Fri, 27 Jun 2008 17:10:31 +0100

> 1000 entries in a database is laughably small.

Probably, but maintaining it apparently is not.

> Downloading it to a phone as

Again, this is for dumb DTMF phones, not smart phones.

> <assignment operator="ATT" use="wireless" prefix="202555" min=4 max=4/>

Yes, but that's ITU-T territory.

Automatically generating Send-N records based on the local ENUM tree 
structure allows (I-)ENUM operators to publish real-time number plan 
pseudo-data without their ever needing to be reference to a "master" 
ITU-T/Regulator number plan.

The master number plan information only needs to be consulted locally to 
figure out whether any given E.164 number is allowed to be put in the ENUM 
database in the first place.

Ray

---

From: [email-masked]
Date: Fri, 27 Jun 2008 17:33:44 +0100

I wrote:

>> The large number of dial plan entries for the UK means that
>> for some number ranges (in particular +44800) they're having
>> to use inter-digit timeouts, and they're not happy about it.
>>
>> The UK carriers are therefore actively trying *not* to have
>> the UK dial plan burnt into their switches, and this is the
>> proposed implementation.

> freephone numbers means that there are numbers in that range with two 

I think I overstated the case there when I said "therefore".

Even without +44800 the operators would like to avoid maintaining call 
plan information in their switches.

Ray

---

From: [email-masked]
Date: Fri, 27 Jun 2008 18:03:25 +0100

> "!^\\+44800(.*)$!sip:44800\\[email-masked]!" .

Sorry, I still don't see your point.

Yes, those NAPTRs would hide any wildcard Send-N record higher up in the 
tree.  Per previous e-mail, "so what?".

A better example would be:

$ORIGIN 0.0.8.4.4.e164.org.

*       IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email-masked]!" 
.
        IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email-masked]!" .
        IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email-masked]!" .
        IN NAPTR 200 10 "u" "E2U+pstndata:send-n"
                "!.*!pstndata:send-n/=12!"

With the absolute form introduced in -01 that's perfectly valid.

> As per my last email you are also breaking ENUM RFCs, not just DNS ones.

Can we please separate out the issues caused by overlapped dialling from 
Send-N itself?

Send-N is a way to mitigate the DNS load in any system that does an ENUM 
lookup as each digit is dialled that also happens to reveal number plan 
information.

It's the overlapped dialling that "breaks" ENUM RFCs, not Send-N.

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jun 2008 14:15:32 -0400

I think we're in the "agree to disagree state".

I do not support Send-N.

I think there is a problem, I think IETF can solve it.  I've provided one
alternative, I'm happy to discuss others.  

Your proposal, in my opinion, is too limiting, and doesn't solve the entire
problem.

Brian

> Sent: Friday, June 27, 2008 12:11 PM
> To: [email-masked]

---

From: [email-masked]
Date: Fri, 27 Jun 2008 20:23:27 +0100

> Your proposal, in my opinion, is too limiting, and doesn't solve the 
entire

Brian,

Can you please explain exactly *how* you find it limiting, and what you 
believe the rest of the "entire problem" is that that's apparently not 
solved?

Ray

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 27 Jun 2008 15:36:10 -0400

It doesn't tell you the length of a number; it tells you how many digits you
have to enter to get to the next step in the revealing of the length of the
number.

The entire problem is that there are a significant number of applications
and systems that need to understand, in detail, the number plan for a
country.  Those include applications such as the one you are describing
(overlapped dialing systems) as well as:
1) An ENUM operator wishing to validate the shape of the tree
2) A smart device wishing to implement a sophisticated digit map
3) A routing engine trying to diagnose why a call is not routing
4) Rating and routing entities who merely need to understand what carrier is
allocated a number block (where not all blocks are number portability
enabled)

Brian

> Sent: Friday, June 27, 2008 3:23 PM
> To: Brian Rosen
> Cc: [email-masked]

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 08:12:19 +1000

> tree.  Per previous e-mail, "so what?".

No those records are wild cards, the hostnames appear in full because
that's how DNS returns them based on the query and any send-n's more
specific would hide those wild cards not the other way round.

It's obvious you and Clive have both failed to grasp why wild cards
would break, so it's more than obvious that those in charge of this
decision making process in my opinion do not have the necessary
technical skills to be making this kind of decision, so you've come up
with a half baked idea that just happens to kind of sort of work and are
trying to get it ratified for who knows what reason if it's going to be
for private use only.

-- 

Best regards,
 Duane

---

From: Roy Arends <[email-masked]>
Date: Sat, 28 Jun 2008 01:48:17 +0200

On Jun 28, 2008, at 12:12 AM, Duane wrote:

> No those records are wild cards,

No they are not.

In DNS, the concept of Wildcard Domain Names only exist in the  
authoritative server. Since you quoted a response message, these  
records may be the result of wildcard domain name processing on the  
server, but are certainly not "wild cards" nor wildcard domain name.

> the hostnames appear in full because

Please re-read what Ray said: "those NAPTRs would hide any wildcard  
send-N record higher up".

Given that Ray could not have known that you actually used an expanded  
wildcard domain name, but assumed
that these are regular, unexpanded Resource Records, he asserted that  
you would have a wildcard domain name at an ancestor name.

> would break,

This is silly. This doesn't "break" wildcards. This is EXACTLY how  
wildcard domain name processing should behave, i.e. an existent name  
has precedence over a wildcard domain name at an ancestor domain.

> so it's more than obvious that those in charge of this
> technical skills to be making this kind of decision,

This assertion is too ad hominem. Please be polite.

> so you've come up

See my previous remark.

Roy

---

From: Duane <[email-masked]>
Date: Sat, 28 Jun 2008 10:03:17 +1000

Roy Arends wrote:

> authoritative server. Since you quoted a response message, these records
> may be the result of wildcard domain name processing on the server, but
> are certainly not "wild cards" nor wildcard domain name.

You say potato I say well who cares, the point is he was welcome to try
the query for himself, the \\1 (dig adds the extra slash) and the .* in
the NAPTR record should have tipped him off to the fact it was a wild card.

> send-N record higher up".

If I do the same query for +44800\d{1,10} and the results would be the
same, yet if a send-n appears at a more specific location the result
wouldn't be the same.

> you would have a wildcard domain name at an ancestor name.

Again, he was free to re-do the query himself if he did not understand
what I was expressing, this isn't supposed to be rocket science but
there is clearly a fundamental lack of understanding here as to the
effect of send-n by its proponents.

> wildcard domain name processing should behave, i.e. an existent name has
> precedence over a wildcard domain name at an ancestor domain.

*sigh* You guys can keep pushing this all you want but you so far
haven't shown why this shoul be accepted it has the potential to
substantially increase load on DNS and cause looping all of which would
need to be dealt with as special cases and even if it was passed as a
NAPTR type the DNS guys would most certainly have a beef with all the
additional queries.

As I said before this seems to be more like a routing protocol,
something in the domain of BGP where everyone has a complete view of the
dial plan and updates are broadcast as they happen.

> This assertion is too ad hominem. Please be polite.

I've tried to be, but that doesn't seem to be working, so I thought a
slightly more strongly worded email might have more of an impact, I
guess I was being naive in assuming what I was expressing was being
understood.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Sat, 28 Jun 2008 10:12:46 +0100

> effect of send-n by its proponents.

Of course I recognised that those were the results of a wildcard in your 
zone file.

I didn't understand that you were talking about Send-Ns appearing in the 
tree below the wildcard point (rather than the other way around) simply 
because there's no good reason for that to happen, it would be 
misconfiguration.

The correct place for the Send-N to appear would be at or above the 
wildcard record itself, as per the example I sent.

In any event, wildcard records such as you showed are incompatible with 
overlapped dialling, precisely because (as per 3761) they return a full 
result for an incomplete number.  That's an issue for NGNs that might 
intend to implement overlapped dialling using I-ENUM and partial number 
lookups, but it's not caused by Send-N.

Ray

---

From: Roy Arends <[email-masked]>
Date: Sat, 28 Jun 2008 15:20:55 +0200

On Jun 28, 2008, at 2:03 AM, Duane wrote:

>> records
> You say potato I say well who cares,

I think it is important to disambiguate statements that seem to cause  
confusion amongst the readers. This is not per se a noble goal, but  
actually a requirement to gain consensus later. I would like to know  
exactly what causes resentment against a certain proposal, even when  
it takes a bit dissecting.

> the point is he was welcome to try

I thought you were referring to wildcard domain names, as in RFC 4592.

> effect of send-n by its proponents.

The odd thing about your statement is that you seem to be convinced of  
a "fundamental lack of understanding to the effect of send-n by its  
proponents", but you then try to educate those "proponents" in a  
fairly hostile, divisive way. This combination does not help your  
case, and for the rest of the list, it is kind of weary to read.

> *sigh* You guys

For the record: I am neither a "proponant or an opponant" of the  
proposed technology. I became part of this discussion because I though  
I could weed out some of the confusion about wildcards in the domain  
name system. In my mind, even with my limited knowledge of the DNS,  
and even less about ENUM, I thought that there is a certain alarmist  
tone in stating that 'send-n breaks wildcards'. It is at least  
ambiguous, as I have showed above.

> can keep pushing this all you want but you so far

There is already a warning in the send-n draft about the combined use  
of send-n records and wildcards.

> guess I was being naive in assuming what I was expressing was being

Well, if you feel that you are being misunderstood, wording your email  
more strongly does not help, and might even have an adverse effect.

regards,

Roy

---

From: Otmar Lendl <[email-masked]>
Date: Sat, 28 Jun 2008 23:05:18 +0200

> published in that Word document as a database anyone, including the enum

In the case of Austria, the regulator only defines bounds for the
length of numbers. Within those bounds, both the number block owner
and the end-user of the number/prefix can define their own dial-plan.

So if you want to cover Austria and Germany with this scheme, you 
either

* accept ranges instead of exact number lengths for some prefixes

or

* provide some on-demand query mechanism for the dial-plan specifics
  within a prefix.

(btw, here is the Austrian numbering plan:
http://www.rtr.at/en/tk/E129/Austrian%20Numbering%20Plan%202004-05-12.pdf
)

/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: Peter Koch <[email-masked]>
Date: Sun, 29 Jun 2008 15:23:25 +0200

Folks,

> overlapped dialling, precisely because (as per 3761) they return a full

not responding to this particular message but trying to find an entry into
this thread, I'd like to apologize for my confusion, but I fail to see
why of all issues wildcards are causing so much rigor here.  As others
have already stated, on the DNS protocol level, wildcards are a provisioning
aid that is expanded at the authoritative server side.  To that extent,
"send-n" NAPTR RRs may not make much sense at a wildcard owner, especially
given that they expand across multiple levels of hierarchy, but I can't
understand why send-n would "break" wildcards or vice versa.  Then, of course,
I also do not understand why "digitsmin" would need a relative interpretation
at all instead of just using the absolute value.
There might be uses of wildcards today which would interfere with "send-n"
or would benefit little or nothing, but so be it.

That said, I believe that "overlap dialing" is an issue that needs a solution,
but I'm not convinced that "send-n" is that solution nor that the solution
space is constrained to ENUM (or I-ENUM for that matter).

"send-n" clearly is not an ENUM service, instead it is a "clever" attempt
for an optimization (incompatible with the DDDS way of query processing)
that is not (yet, maybe) strongly motivated in the draft: it adds complexity to
the protocol and increases the data set to be provisioned to reduce the number
of DNS queries.
But who is this optimizing for?  Is it to reduce the query load for authoritative
servers or to reduce response latency for the clients?  For the first, where are
the motivating load predictions and usage scenarios?  For the latter, why
would that matter, given that we assume a human to dial the numbers anyway?
Did anyone say per-query-billing?

This is clearly not an ENUM service, but a "clever" optimization that is
not compatible with the DDDS way of query processing.

   This additional information is encoded within NAPTR records since
   this avoids the need for applications to issue multiple DNS requests
   with varying QTYPEs depending on the type of information being looked
   up.

Yes, if all you have is TXT, you don't need any differentiation.

What also concerns me is this paragraph in section 5:

   information supplied by the local numbering plan administrator.  It
   is expected however that Send-N records would be synthesised
   automatically by the DNS server based on the information currently
   stored in its ENUM database.

Does "synthesised automatically" express the intent to generate these
responses on-the-fly or prior to loading the DNS zone, based on some
automated tool?

-Peter

"ceterum censeo": If it is really necessary to apply the proposed optimization,
  it might be time now to re-think the applicability of "ENUM technology" for the
  I-ENUM problem space, go back to the drawing board and come up with
  a solution that is less dependent on DNS.
_______________________________________________
enum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/enum

---

From: [email-masked]
Date: Mon, 30 Jun 2008 10:36:55 +0100

> or would benefit little or nothing, but so be it.

Thanks Peter, hopefully that puts the wildcard issue to bed.

[btw, the original reasoning for using relative rather than absolute was 
to avoid the need to regenerate the RRs if a portion of the number space 
gets moved into a new prefix of different length]

> space is constrained to ENUM (or I-ENUM for that matter).

"Send-N" is not "the" solution for overlapped dialling.

IP-based Next Generation Networks will in general use I-ENUM.  If we 
assume that to support overlapped dialling those networks do lookups on 
partial numbers (as is the plan in the UK) then "Send-N" is simply an 
optimisation method in those circumstances.

> for an optimization (incompatible with the DDDS way of query processing)

It's not the "Send-N" part that's incompatible with DDDS, it's the partial 
number lookups.  As I understand it the requirement to only do full number 
lookups in RFC3761 is there purely for performance reasons.  Personally I 
think it's too strong, and that standards shouldn't put "MUST" in unless 
something would break if the rule was broken.

The one place that partial lookups does break are in ENUM zones with 
wildcards in (like Duanes).  Ironically in that case a "Send-N" record 
actually helps.  It could tell the client that although a record has been 
returned (through wildcard processing) it's not valid because not enough 
digits have been supplied.  The SIP server could return a "484 address 
incomplete", but that means handling and rejecting several extra SIP 
INVITEs.

> that is not (yet, maybe) strongly motivated in the draft: it adds 
> complexity to the protocol and increases the data set to be provisioned 
to
> reduce the number of DNS queries.

Yes, that's right.  More data is provisioned to make tree traversal more 
efficient.  It's a time vs space trade-off.

> But who is this optimizing for?  Is it to reduce the query load for 
> authoritative servers or to reduce response latency for the clients?

It's both, really. 

Use of "Send-N" reduces the query load substantially (see below) and also 
eliminates the need for inter-digit timeouts, which substantially improves 
the end-user experience.

> For the first, where are the motivating load predictions and usage 
scenarios?

For the UK we've determined that once we've got as far as +44, a maximum 
of just *two* Send-N lookups are required.

There's one particularly short number in our E.164 plan (+448001111).  So 
looking up 4.4.e164.nicc.org.uk would return a Send-N of 7 (or =9). Having 
received those further 7 digits that happens to be sufficiently far down 
the tree that the next lookup will return either 2 (=11) or 3 (=12) and 
either of those will be the final result.

> For the latter, why would that matter, given that we assume a human to 
dial
> the numbers anyway? Did anyone say per-query-billing?

Per-dip charges aren't an issue in the UK model as each carrier is allowed 
(indeed expected) to secondary portions of the number space into DNS 
servers on their own network.

> Yes, if all you have is TXT, you don't need any differentiation.

Sorry Peter, I don't understand that comment.

> "ceterum censeo":

In the authoritative server they'd probably be created as the zone is 
populated rather than in real-time.  I'll rephrase that.  In secondaries 
they'd be part of the IXFR data, just like any other RR.

> If it is really necessary to apply the proposed optimization,
>   it might be time now to re-think the applicability of "ENUM 
> technology" for the I-ENUM problem space, go back to the drawing
> board and come up wi  a solution that is less dependent on DNS.

I believe it's too late for that.  The NGNs are already well on the road 
to using I-ENUM.

cheers,

Ray

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 15:38:42 +0100

> gets moved into a new prefix of different length]

This is something that has happened before and might happen again - more
importantly, there may well be a period of parallel running - so it was
worth taking into consideration.

> the tree that the next lookup will return either 2 (=11) or 3 (=12)

or 1 (=10) in a few cases.

> and 

That appears to be the case right now. It's possible that there will be
some edge cases in the future where there will be one more lookup (that is,
the sequence is =9, =11, =12, result). These will be transitional, though,
as a particular number space is dynamically lengthened.

> they'd be part of the IXFR data, just like any other RR.

In other words, the intent is that when new data is entered into the
primary authoritative server, a process would be run that calculates the
Send-N records based on that data and the existing contents. Those records
would then be added to the server in the normal way. No, this wouldn't be a
standard DNS server doing this.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 15:42:58 +0100

> No those records are wild cards,

No, they aren't. They may have been synthesised from wildcards, but there
is no way to determine that from what you wrote.

> It's obvious you and Clive have both failed to grasp why wild cards

Perhaps that's because you're unable to explain yourself coherently (see,
other people can do gratuitous insults as well as you).

Or perhaps that's because they don't break.

> with a half baked idea that just happens to kind of sort of work

PKB.

> and are

Unless someone comes up with a clear reason not to do so, the UK *will* be
going ahead with this. The proposal is being brought to IETF because we
felt it might be useful for other people, so it should be offered to the
IETF process. But failure to make this an RFC will have *zero* effect on
its real-world implementation.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 16:03:29 +0100

Brian Rosen said:
> document by the ITU.

No, it isn't. Some information that is part of what is needed is published.
But neither the UK nor the Austrian regulator (to pick two) publish
complete and consistent information about the dial plan.

> something like the MGCP dial plan

Is there going to be a single central repository, or a tree with sub-trees
delegated to the various authorities who determine the actual data? The
latter sounds more sensible to me. It also sounds very much like DNS.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 15:51:08 +0100

> the NAPTR record should have tipped him off to the fact it was a wild card.

No, they merely show that a standard pattern was used.

> same, yet if a send-n appears at a more specific location the result

The same happens if you put an A record at a higher level. So don't do that.

But that's not "broken". It's "working correctly".

> what I was expressing,

And the response will fail to demonstrate that a wildcard was used.

> NAPTR type the DNS guys would most certainly have a beef with all the

Actually, it has the potential to greatly reduce the number of queries. As
Ray has pointed out, it reduces 11 queries to 3 or 4.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 16:17:03 +0100

> numbers means that there are numbers in that range with two different  

It's not just that case. The Austrian numbering plan has related issues, if
I'm understanding correctly. And no doubt other countries too.

> part of that country's number plan.

It's also an issue of how to get dial plan information out to everyone who
might possibly need it. That needs to be a pull system, not a push one,
since there will be far too many potential users to keep a master list; we
don't even know who all those users might be. It needs to allow for
delegated databases rather than requiring a single authoritative source who
has to update everything, since we don't know how often updates will happen
(often in Austria, I believe). It ought to allow for cacheing. And it ought
not to require everything to be downloaded again just because one leaf of
the tree has changed.

Remind you of anything?

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 30 Jun 2008 15:52:15 +0100

> get back the right number.

Perhaps. See below.

> more send-n.  This continues, each time you have to query the database.

Yes, modulo cacheing of DNS records.

However, if you're calling a number in Oxford from the US, there will be
four lookups for a 5-digit number (+4, +44, +441865xxx, +441865xxxxx), and
five for a 6-digit number. If you're calling London, Cambridge, or much of
the UK, there will be four lookups.

I actually expect the proxy to have a *very* simple dial plan built in to
it. For the UK, this would be something like:

(1) Same-area call (first digit is 2 to 9): collect N digits, prefix the
local area code, and do a lookup. The value of N will depend on the area
that the proxy is located in, but will be between 4 and 8. In most areas
this will collect the correct number of digits for the call; in some, it
will require another digit or two.

(2) National call (first two digits are 01 to 09): collect N digits,
replace the 0 by +44, and do a lookup. N is either always 8 or is
{9, 11, 11, -, 10, -, 11, 8, 11} based on the second digit. In most cases
this will be the correct length or will give a SEND-N record giving the
correct length; in a few cases it might be necessary to fetch a second
SEND-N record on the way.

(3) International call (first two digits are 00): collect 5 digits (or
possibly more; is there a minimum length for E.164 numbers?). Replace 00 by
+ and do a lookup. How many more fetches are done will depend on the number
plan and database contents for the destination country.

> amount of effort.

Huh? How is 4 lookups "about the same" as 11?

> Probably my solution uses more memory, but so what.  I

I wonder if I'm misunderstanding your solution. Perhaps you can explain it
fully.

> agree; that's a problem worth solving.

Good.

> You have a solution in mind to that

I'm not clear what the problem is for non-overlapped devices.

---

From: Peter Koch <[email-masked]>
Date: Mon, 30 Jun 2008 18:08:05 +0200

Ray,

> gets moved into a new prefix of different length]

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?
Also, since you mention renumbering, is this mostly aimed at PBX installations?
Would your model envision those number ranges to be delegated out of the
I-ENUM tree?

> optimisation method in those circumstances.

Well, yes, but the check for "partial" vs. "full" number need not happen
within ENUM then.

>From the DDDS perspective partial numbers would just not resolve.
"Send-N" piggybacks info on top of "does not resolve" and starts a new
DDDS resolution cycle.  That's not too sound IMHO.
"Send-N" stuffs lots of metadata in the tree that I think doesn't belong there.

> eliminates the need for inter-digit timeouts, which substantially improves 

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?

> servers on their own network.

That's exactly what I hear, too.  So, why would RTT latency matter?

> Sorry Peter, I don't understand that comment.

Apologies.  NAPTR is becoming the TXT RR for enum; everything can be put
in there so conveniently, especially using "data" type URIs.  That's not
what NAPTR was designed for.  And the fact that NAPTR is asked for and thus
this metadata can be sent by way of NAPTR appears more a bug than a feature
to me.  There were reasons that Patrik's earlier draft for 3761bis
actually had service specific discriminators.

> they'd be part of the IXFR data, just like any other RR.

OK, so "sythesized automatically" would be comparable to the way NSEC or
NSEC3 RRs are built: not manual, but they become part of the normal zone
data (not completely true for NSEC3, but different story).  Thanks for
the clarification.

> I believe it's too late for that.  The NGNs are already well on the road 

I'm sorry, but your proposal is only one in a line of "tiny optimizations"
needed for the "perfect fit" of "ENUM technology", or DNS in general,
for the LUF/LRF problem.  That could be perceived as a big "wrong way"
sign on that road.

-Peter

---

From: [email-masked]
Date: Mon, 30 Jun 2008 17:27:10 +0100

> - to me - unclear frequency of occurence, would much be lost with using

Personally I'm not sure.  Clive thinks relative is useful.

> Also, since you mention renumbering, is this mostly aimed at PBX 

No, at carrier level switches.

> Would your model envision those number ranges to be delegated out of the

It's theoretically possible, but not expected.
 
> DDDS resolution cycle.  That's not too sound IMHO.

I've been trying to break apart the confusion between overlapped dialling 
and Send-N.  It's the former that starts a new DDDS resolution cycle.  The 
latter shortens the number of times it might happen.

> "Send-N" stuffs lots of metadata in the tree that I think doesn't 

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?

> of latency over just querying after each digit pressed?

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

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.

> to me.

Ah, yes.  I was advised that the "pstndata" Enumservice and URI scheme had 
been devised specifically to mitigate the way that people were making up 
arbitrary "data:," URI formats or otherwise sticking stuff in TXT records. 
 Hence why this draft draws on Richard's stuff in the CNAM draft.

> for the LUF/LRF problem.  That could be perceived as a big "wrong way"

For the UK NGN standards, this is about as far as DNS goes.  The LUF/LRF 
is still going to be done with bilateral interconnect agreements.

Ray

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 30 Jun 2008 18:28:27 +0100

----- Original Message From: <Ray.Bellis@....org.uk>

>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?)  This seems bad practice to me.  Ideally there would be 
some authorative data set that was the input to the scripts and the whole 
process would be automated.

So the pros and cons of the relative form seem to be:-

Benefits of keeping relative form:
- Might use less (disk) space (although I don't think so).
- Easy to migrate an existing number prefix to another one without 
re-running a script.

Benefits of getting rid of relative form:
- (disk) space is not that important.
- Avoids encouraging bad practice of tweaking output of script processes.
- Gets rid of the wildcard issue (I'm still don't understand whether this is 
a real issue, but as a minimum it saves list bandwidth!)
- Means clients have only one type of result to process (absolute) rather 
than two (which requires more testing etc).

So, when a number plan does change (of the sort I'm used to in the UK 
anyway), knocking up another set of zones seems a trivially unimportant 
thing to optimize compared to all the other things that have to happen when 
such a change takes place (such as informing all the users, re-printing 
directories, installing IVRs that say "we'll route you this time, but in 
future you should dial this number..." and so on).

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

Regards,

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

---

From: Eleanor McHugh <[email-masked]>
Date: Mon, 30 Jun 2008 20:44:32 +0100

On 30 Jun 2008, at 17:27, [email-masked] wrote:
>> expiration
>> would the full number be submitted to the ENUM lookup mechanism.

For a human user manually entering a telephone number into a  
traditional handset there's going to be a minimum practical dialling  
time (approximately 2-3 seconds) following which a further delay of up  
to 2 seconds is going to be perceptually bearable. The acceptable  
dialling time is reduced if automation is part of the process, but as  
long as the call is being placed on behalf of a human those couple of  
seconds to connect the call are the primary differentiating element  
between 'good' and 'lousy' service levels.

Of course there are also use cases where a human intermediary is  
connecting the call (PBX or Telco operator assistance or Emergency  
Service) where the resolution of the second leg has to be perceptually  
near-instantaneous to match user expectations but I don't know enough  
about the interplay of ENUM with those services to comment on their  
relevance to this discussion.

>> what NAPTR was designed for.  And the fact that NAPTR is asked for  
>> and
>> thus this metadata can be sent by way of NAPTR appears more a bug  
>> than a
>> feature to me.
>

Storing significant volumes of data directly in NAPTR records as as  
unwieldy process as doing the same with TXT records thanks to TTLs and  
payload limitations. Where NAPTRs do shine though is in providing  
public APIs via URI rewriting for RESTful data services, but that's a  
whole different discussion.

Ellie

Eleanor McHugh
Games With Brains
[email-masked]

---

From: Duane <[email-masked]>
Date: Tue, 01 Jul 2008 08:12:45 +1000

> not to require everything to be downloaded again just because one leaf of

Yup, BGP

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 01 Jul 2008 08:19:18 +1000

> The same happens if you put an A record at a higher level. So don't do that.

Only if you request ANY/ALL, if you specifically request NAPTR it
shouldn't, which is why someone else suggested you make a new DNS type
to store send-n against then naptr wouldn't break except for the case
where someone requested ANY/ALL

> And the response will fail to demonstrate that a wildcard was used.

I'm sorry that I couldn't show a bind zone file, however bind just
didn't scale for us and I was trying to show live/real data, we ended up
coding our own software and using a DB4 backend and a copy and paste
from it would have made even less sense.

-- 

Best regards,
 Duane

---

From: Roy Arends <[email-masked]>
Date: Tue, 1 Jul 2008 00:36:58 +0200

> where someone requested ANY/ALL

Regardless of the type at the higher name, simply the existence of a  
name will cause wildcards not to expand for that name.

As an example using the following records:

bob.harry.example TXT   test
*.example           NAPTR [whatever]

Will cause the following queries NOT to result in a wildcard expansion:

example NAPTR
harry.example NAPTR
bob.harry.example NAPTR
john.bob.harry.example NAPTR

All these will lead to NODATA errors (RCODE=0 plus empty answer section)

Regards,

Roy

---

From: Duane <[email-masked]>
Date: Tue, 01 Jul 2008 08:41:04 +1000

> name will cause wildcards not to expand for that name.

Right so they should look into developing a proper routing protocol,
something like BGP, which would give smart switches a complete view of
the dial plan and then wouldn't need to send out dns queries and rely on
third party systems being available since the information could be
cached locally until an update arrived changing some routing information.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Tue, 01 Jul 2008 10:45:12 +1000

Richard Shockey wrote:

> Yea and we all know where TRIP went ... 

TRIP wasn't just about routing though.

If all you are broadcasting is prefix lengths then there should be no
issue, if you want to start introducing all kinds of complexity and
other additional information such as price updates for routes then that
is a different issue altogether.

-- 

Best regards,
 Duane