Review of draft-bryan-sipping-p2p-02.txt

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.


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.