OVERVIEW
This draft describes a protocol and architecture for doing
"P2P SIP". What this means in practice is that registration
information is stored in a Distributed Hash Table, thus
in principle removing the need for centralized servers.
GENERAL COMMENTS
Use of SIP for DHT Functions
----------------------------
The protocol used in this draft uses SIP both for the usual
signalling functions and for DHT maintenance. This strikes
me as a poor design decision.
1. It means that while you will be able to use generic
DHT algorithms you won't be able to use a generic
DHT service. There's nothing particularly special
that this application requires from a DHT, so it seems
like a classic architectural mistake to tie yourself
to something specific.
2. It obscures what should be a clean architectural separation
between lookup services (what the DHT is being used for)
and signalling services (what SIP is used for now). This
made some sense in the previous draft which actually
punned on the SIP messages (using INVITE to find the
UA for the desired contact) but now that you're using
REGISTER in order to explicitly separate these functions,
there's really no value added here.
3. It's really confusing.
Security
--------
