Re: Send-n, rat holes and real issues

I can only speak from the perspective of having a variable length dialling plan nationally, and having to deal with complex number length tables internationally.  I'm no DNS expert so this is from a requirements perspective;


> 
> and the second two are specifically about send-n:
> 
> c. Is the relative form of send-n worth the trouble?

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.

> 
> d. Is the trade off between extra records vs reduced lookups worth it?
> 

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

> 
> Any more real issues?
> 
> Jay
> _______________________________________________
> enum mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/enum
> 

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ