Re: Send-N draft: draft-bellis-enum-send-n-02 published
| 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