Last Call Review of draft-ietf-ppsp-base-tracker-protocol-10
review-ietf-ppsp-base-tracker-protocol-10-opsdir-lc-brownlee-2015-10-19-00

Hi all:

I have performed an Operations Directorate review of
   draft-ietf-ppsp-base-tracker-protocol-10

  "This document specifies the base Peer-to-Peer Streaming Protocol-
   Tracker Protocol (PPSP-TP/1.0), an application-layer control
   (signaling) protocol for the exchange of meta information between
   trackers and peers.  The specification outlines the architecture of
   the protocol and its functionality, and describes message flows,
   message processing instructions, message formats, formal syntax and
   semantics."

- - - -

This is a long document describing in detail a protocol that can be
used to form a network of co-operating peers, supporting swarms for
particular content streams, and distributing that content to all peers
that are members of the stream.

The formal presentation of the protocol uses a C-style notation, and
encodes its requests and responses using JSON.  It seems to me that
there has been at least one implementation to date, therefore the
Object definitions are taken from that implementation's source code.
Reading them, I believe that the protocol is described clearly enough
to allow other independent implementations.

Having said that, there are several items which are not covered, for
example in section 1.2.2 "The specification of the format of the Peer
ID is not in the scope of this document."  I'm sure there's a good
reason for leaving that out, but implementors will need to make sure
that Peer IDs are always treated as strings (as specified in section
3.2.4).

Section 5.1, Operational Considerations, seems carefully considered;
it provides a checklist of things a service provider will need to
consider when they deploy PPSP-TP.  In particular section 5.2
(Management Considerations) points out that Management Information,
including that for Fault, Configuration, Accounting, Performance and
Security Management all expect to use other existing techniques.
That's reasonable, of course, but providers will need to plan
carefully for all that.

Section 6, Security Consideration, seems thorough, pointing out that
peers will need to cope with various kinds of other - potentially
malicious - peers.

Last, section 7 provides some guidelines for extending PPSP-TP.
This is certainly interesting, clearly the authors view PPSP-TP
as an ongoing development activity!

Overall, this document seems sound, i.e. ready for publication
as an RFC.

A few typos:
  s1     s/peers able to communicate/peers that are able to communicate/
         s/different order of the/different order to that of the/
  s1.2   s/here, as not in the scope/here, as it is not in the scope/
          /swarms corresponding each swarm to the group of peers/
             what does this mean?
  s2.2.3 s/On normal operation/In normal operation/
  s2.3.1 s/respectively responded with/respectively responded to with/
         s/responded with/responded to with/
  s2.3.2 s/transition to TERMINATE/transitions to TERMINATE/
  s3.2.5 s/peer is actively involved./peer is actively involved with./
  s4     s/The section describes/This section describes/
  s4.1.2 s/include peer_group element/include a peer_group element/
  s4.1.3 s/concurrent_links and etc./concurrent_links etc./
  s4.3   s/due to unexpected/due to an unexpected/
  s4.4   s/set a upper/set an upper/
  s7.2   s/Being security an important/Because security is an important/

Cheers, Nevil
Co-chair, SUPA WG

--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand