Thus my assumption that this document is targeted at the gap above is
correct. Then one should not be finding the best tunnel _endpoint_ but
the tunnel _service_ which can provide that endpoint. TSP for instance
does its own endpoint negotiation. Having a discovery method do that
would thus make TSP either be only for that single Tunnel Server or it
would require another step. The 'endpoint' wording thus is wrong IMHO
and should be resplaced by 'service'.
Again, I disagree.
Let's take TSP as an example as you mention it. TSP has a great
"gaping gap" (in your words): there is no way to discover the closest
tunnel broker!
For tunnel broker solutions, this document tries to address finding
the tunnel broker end-point (where you can begin the negotiation).
The tunnel broker negotiation specifies the ultimate endpoint where
you'll build your tunnel (such address could of course be anycast or
whatever as well). What happens after getting the initial broker
end-point it out of scope of this specification.
For tunnel server solutions, this document tries to address finding
the tunnel server end-point (where you can beging tunneling or
negotiation, whatever the mechanism specifies).
So, I have to disagree with you here. We just want to discover the
end-point.
Any suggestions how to make it clearer?