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

Ray,

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

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?

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

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

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

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.

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

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?

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

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

> > Yes, if all you have is TXT, you don't need any differentiation.
> 
> 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.

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

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.

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

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