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

> > Can you provide an actual example zone showing how this doesn't work?
> 
> ;; QUESTION SECTION:
> ;9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. IN NAPTR
> 
> ;; ANSWER SECTION:
> 9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
> "!^\\+44800(.*)$!sip:44800\\[email protected]!" .
> 9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
> "!^\\+44800(.*)$!sip:44800\\[email protected]!" .
> 9.8.7.6.5.4.3.2.1.0.0.8.4.4.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP"
> "!^\\+44800(.*)$!sip:44800\\[email protected]!" .

Sorry, I still don't see your point.

Yes, those NAPTRs would hide any wildcard Send-N record higher up in the 
tree.  Per previous e-mail, "so what?".

A better example would be:

$ORIGIN 0.0.8.4.4.e164.org.

*       IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email protected]!" 
.
        IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email protected]!" .
        IN NAPTR 200 10 "u" "E2U+SIP"
                "!^+44800(.*)$!sip:44800\[email protected]!" .
        IN NAPTR 200 10 "u" "E2U+pstndata:send-n"
                "!.*!pstndata:send-n/=12!"

With the absolute form introduced in -01 that's perfectly valid.

> As per my last email you are also breaking ENUM RFCs, not just DNS ones.

Can we please separate out the issues caused by overlapped dialling from 
Send-N itself?

Send-N is a way to mitigate the DNS load in any system that does an ENUM 
lookup as each digit is dialled that also happens to reveal number plan 
information.

It's the overlapped dialling that "breaks" ENUM RFCs, not Send-N.

Ray