- 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