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

[email protected] wrote:
>>> 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?".

No those records are wild cards, the hostnames appear in full because
that's how DNS returns them based on the query and any send-n's more
specific would hide those wild cards not the other way round.

It's obvious you and Clive have both failed to grasp why wild cards
would break, so it's more than obvious that those in charge of this
decision making process in my opinion do not have the necessary
technical skills to be making this kind of decision, so you've come up
with a half baked idea that just happens to kind of sort of work and are
trying to get it ratified for who knows what reason if it's going to be
for private use only.

-- 

Best regards,
 Duane

_______________________________________________
enum mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/enum

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIZWXDEpWoZMmo/c8RArG6AJ9vWVRBNUoomdQp+Y49JZFqQxwAEgCgtLl+
reFeuyrlPKkTlStQyuB27OA=
=qq6g
-----END PGP SIGNATURE-----