Send-n, rat holes and real issues

It appears to me that this discussion is actually getting somewhere 
sensible.  The following rat holes appear to have been exposed as bogus:

1.  This is not /just/ about a fully populated tree for a national number 
space.  If you take a different example, like a tree of only ported 
numbers, or a private tree shared by a group of carriers then it does not 
matter what the regulator knows. 

In those cases the shape of the tree is determined by the data that is put 
in it and _solely_ by the data put in it, so no outside data 
representation is of any use.  Protocols that describe the dial plan or 
numbering plan are orthogonal to this draft.

2.  The views of some people that overlapped dialling should not be used 
cannot be tackled by this draft.  It exists, it is used and that is that. 

3.  According to all the DNS experts the treatment of wildcards is not an 
issue.



So that leaves us with the following real issues that are actually worth 
discussing.  The first two are more about DNS:

a. Whether or not we need a more general mechanism to describe the shape 
of the tree rather than the something just for ENUM?  Also expressed as 
whether there should be meta-data in the tree about the tree (and whether 
NAPTR is a good way to do that)?

b. What is the trust/security implication from one label in the tree 
making a statement about later labels in the tree even though they might 
be under different administrative control?


and the second two are specifically about send-n:

c. Is the relative form of send-n worth the trouble?

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


Any more real issues?

Jay