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

[email protected]
Newsgroups gmane.ietf.enum
Message-ID <OF1C14AA6D.A2F836BD-ON80257476.003154F1-80257476.00329B57@nominet.org.uk>
> Again, he was free to re-do the query himself if he did not understand
> what I was expressing, this isn't supposed to be rocket science but
> there is clearly a fundamental lack of understanding here as to the
> effect of send-n by its proponents.

Of course I recognised that those were the results of a wildcard in your 
zone file.

I didn't understand that you were talking about Send-Ns appearing in the 
tree below the wildcard point (rather than the other way around) simply 
because there's no good reason for that to happen, it would be 
misconfiguration.

The correct place for the Send-N to appear would be at or above the 
wildcard record itself, as per the example I sent.

In any event, wildcard records such as you showed are incompatible with 
overlapped dialling, precisely because (as per 3761) they return a full 
result for an incomplete number.  That's an issue for NGNs that might 
intend to implement overlapped dialling using I-ENUM and partial number 
lookups, but it's not caused by Send-N.

Ray
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.