Re: Send-N draft: draft-bellis-enum-send-n-02 published

Folks,

On Sat, Jun 28, 2008 at 10:12:46AM +0100, [email protected] wrote:

> In any event, wildcard records such as you showed are incompatible with
> 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.