Re: Send-n, rat holes and real issues

Rosbotham, Paul wrote:

> The relative form arose partially from a standpoint of simplifying
> renumbering, but more for historic reasons.  Our UK variant of C7 has
> the concept of SND(n), which terminating switches send back to
> originating switches when the number length is insufficient, asking
> for n more digits.  The concept of SEND-N in DNS was devised to mimic
> that, albeit with a database (DNS) providing the info rather than the
> terminating node.  Since SND(n) gave the number of extra digits
> needed, SEND-N did the same, in order to keep the call handling
> engine the same.  If it causes issues, I wouldn't die in a ditch
> about it.

Just because that's what happened in the past is no reason to keep doing
the same thing if there is better ways to achieve the same result.


> Given the hassle of maintaining the number length tables, I'd say an
> emphatic yes.  It's all very well saying ENUM is specified to be
> queried with a complete number, but that's precious little use if
> you've no idea whether the number you've got is complete or not.
> Take a look at Section 3.3 of
> http://www.nicc.org.uk/nicc-public/Public/guidelines/nd1423_2007_06.pdf
> , which provides an overview of number lengths in some countries and
> it'll become clear how complex that is.  Regretably, regulators (more
> properly numbering plan administrators) aren't always the best at
> publishing correct information hence there's various international
> informal circles of databuild guys continually trying to update the
> pieces of the jigsaw (not to mention commercial organisations who'll
> help for a fee).  I know there's information at the ITU-T
> website...as it happens I initiated that about 7 or 8 years ago...but
> it's far from comprehensive.  So in a fully populated ENUM situation
> incorporating nu mber length info seems a pragmatic way forward.
> 
> In a partially populated situation as you subsequently described, it
> seems to me even more so.  What matters is the length of the numbers
> in there, not the theoretical length of numbers that would plug the
> gaps.

Again, where is the flaw in using a BGP like distributed routing table,
this would seem to be the most efficient to me, since nothing would need
to make any requests until the internal dial plan conditions were met.

The only data broad casted outwards would be incremental updates as
information changes, rather than keep banging away at DNS requests until
everything is satisfied that the full number is done.

Unlike TRIP this shouldn't be used to update route costs as well, a very
very simple protocol carrying just the numbering length.

-- 

Best regards,
 Duane