- brak wyjaśnienia, skąd się wzięły przyjęte wartości stałych - brak uzasadnienia wybranych protokołów - Głos po TCP to zły wybór ze względu na duży narzut, retransmisja utraconego pakietu głosowego nie ma sensu - do każdej rozmowy musi zostać postawiony na "porcie sterującym WLT" nasłuchujący serwer RPC, co daje spory koszt - dziury w bezpieczeństwie - TCP jest w miarę (choć nie tak znowu bardzo) odporne na wrzucanie dowolnych komunikatów do strumienia przez osobę trzecią, w RPC jest to utrudnione, gdyż strumienia nie ma i każdy może sobie wysłać polecenie RPC na linię sterującą WLT, podszywając się wpisując nie swoje "ja" - kiepsko wygląda możliwość wyboru do zajęcia linii, która jest zajmowana przez kogoś innego - do poprawności protokołu losowego czekania potrzeba jeszcze, by nie ponawiać prośby zajęcia danej linii przez pewien losowy czas (którego średnia wartość powinna rosnąć wykładniczo przy kolejnych niepowodzeniach) - jak mają być obsługiwane przedawnienia komunikatów? Osobny timer do każdego komunikatu, do którego to się stosuje? A może RPC samo to zrobi? Nie jest to częścią protokołu, tylko implementacji, ale jedno zdanie na ten temat rozjaśniłoby sytuację implementatorowi - interpunkcja ;-) + implementowalność + realizuje wyspecyfikowane funkcje + dość prosto i przejrzyście napisane + ładny i poprawny opis odbierania połączenia w grupie + poprawny i działający schemat dołączania do grupy - co przy obustronnej próbie zawieszenia? ~ czy potrzebne są definicje wszystkich stałych liczbowych, czy niektóre można zostawić implementacji? W sumie: 4