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