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

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

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]

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

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

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.

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

Sorry Peter, I don't understand that comment.

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

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email protected], t: +44 1865 332211