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

Ellie

> What makes send-n interesting is that it's neither a link nor a 
> resource, but introspective meta-data. I can see the logic of a 
> standard NAPTR that links to this data by generating an appropriate 
> URI but using a NAPTR to embody the data itself feels somewhat akin to 
> using an HTTP GET resource to update a database. This is the reason I 
> feel send-n would be better handled via a different RR type 
> specifically geared to tree introspection and validation.
> 
> I can't comment on whether or not such a generic solution has uses 
> beyond ENUM or how acceptable it will be to the wider DNS community.

I can see the attraction but this is more a thought experiment than a 
practical solution.  This is because 

* it has no use case;
* the security implications are too great of one label being able to make 
statements about lower labels that might be under different admin control.

If you think it is a good idea then please suggest it to dnsext, but I 
suspect it will not get much traction.  Hence my view that send-n is best 
as it is, a limited solution for ENUM.

Jay