Peer-to-Peer Streaming Tracker Protocol (PPSTP)
RFC 7846

Note: This ballot was opened for revision 10 and is now closed.

(Martin Stiemerling) Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2015-11-13 for -10)
No email
send info
Thanks for addressing my discuss point in email discussion. I'm clearing the discuss under the assumption the proposed text will make it into the next revision.

- 1.1, definitions of "LEECH" and "SEEDER"

These don't seem to match the  use of the terms elsewhere in the document. In particular, these seems to describe transient states, while the protocol requires the peer to declare itself to be a leech or seed when it joins a swarm. Additionally, these definitions don't seem to consider a peer that may have received part but not all of some content, but still makes the chunks it has available.

- 1.1, LIVE STREAMING:

Is there an expectation of syncing reception between receivers? 

- 1.1, VIDEO-ON-DEMAND
Aren't the main points that different audiences can watch the same part at different times, or different parts at the same time?

- 1.2, 2nd to last paragraph:

Wouldn't a distributed tracker have implications for discover and connection management? It also seems worth some discussion in the operations section.

- 1.2.2, first paragraph:

Aren't there at least some implied requirements for peer-ids? E.g. uniqueness requirements? Requirements for elements to treat them as opaque strings?

-2.1: "The messaging model of PPSP-TP aligns with HTTP protocol..."

Is that the same as saying it uses HTTP as a substrate? (If so, the references to HTTP need to be normative.)

- 2.2, 3rd paragraph: "Requests are sent, and responses returned to these requests."
The use of passive voice obscures the actors. What does each of these things?

- Figure 5: Is there a matching peer state machine (i.e. that models the internal state of a peer?)

- 2.3.2, general:

The section is inconsistent in specifying result codes. Also, it's not clear whether these are HTTP result codes, or PPSP-TP result codes.

-2.3.2: "Peers MUST NOT generate protocol elements that are invalid."

That's an odd use of "MUST NOT". 

ability_nat: What's the use case for one peer caring what the NAT status of other peers might be, as long as it gets addresses that it can reach?

- 3.2.4: "connection":
That list will continuously become obsolete. I suggest some classification that describes the attributes you care about, rather than the current-as-of-now set of network technologies.

- table 3:

How is "priority" encoded and interpreted?

-3.3.4:

"Normally, swarm action result
   elements SHOULD be set and error_code MUST be set to 0 when
   response_type is 0x00."

What does it mean for swarm action results element to be set? Since that's a structure, I assume you don't mean set as in "true", or set to zero like the error_code. Do you mean they should be _included_ or _present_?

"A swarm action result element is the result information for a peer to
   request the tracker to have some actions towards the swarm."

I'm a bit confused about the causality here. This is the result of a request that has already happened? An indication that the pier should request something? A reciprocal request and the result of the previous request?

-4, general:

The protocol specification sections are inconsistent in the way they use 2119 keywords. It seems somewhat random whether any given protocol requirement uses 2119 keywords or not. I suggest the authors re-review this section for 2119 consistency. In general, you don't need 2119 words to describe every detail of the the basic flow of the protocol; rather they are more useful when there's a decision to make, or a place where an implementor is likely to get things wrong.

-4, 2nd paragraph:

Can you offer any guidance on when one should actually _use_ HTTPS? (See DISCUSS comment)

-4, paragraph 4:

This seems to be describing the general working of HTTP. I'm not sure why you need to restated it here, especially with 2119 words.

-4.1.1, paragraph 4:

Since the mentioned elements are "optional", is there any guidance for the tracker? For example, can the peer assume that the tracker (or other peers) will never require these elements to operate properly? Or if they may be required by the tracker (or other peers), how would the peer know it needed to include them?

- 4.1.1, paragraph 6:

"... MAY... start by pre-processing the peer authentication information" needs elaboration. I assume the "MAY" relates to the previously mentioned "preferred" use of TLS client certificate authentication?

-4.1.1., 3 paragraphs from end:

Can you elaborate on "STUN-like function"? I gather the tracker can reflect back the observed source address/port of the peer in the response? If so, I'm not sure readers will understand that from "STUN-like function".

-4.1.1.1:

I'd love to see the example use HTTPS, just to set a good example.

In the example of a peer leaving one swarm and joining another, second swarm_action:

s/@peer_mode/peer_mode

-4.3, 1st paragraph:

Why would the peer fail to read the response? Because the response is invalid? Not received? This all runs over TCP right?

-4.3, 3rd paragraph:

Why only a should? What are the consequences of not being prepared?

I assume the errors in this section are PPSP-TP errors, not HTTP result codes. I think the choice of 4XX codes will confuse people into thinking these match the HTTP 4XX client-error result codes. Especially since many seem to have similar meanings--but rearranged.

-6.1:

It would probably be worth mentioning the need for an enrollment service in the operations section.

The 3rd paragraph would work better in the previous paragraph where you mention the HTTP security considerations, and perhaps cast in terms of HTTPS. Also, please consider a reference to RFC 7525.


OAuth might should've been mentioned back when you discussed digest authentication and HTTPS client certificates 

-6.2:

This seems to mean that the peers in a swarm must agree on an integrity protection mechanism. Can you reference something? On the other hand isn't this an issue for the actual transport protocol rather than the tracker protocol?

-7:

The 3rd paragraph seems to forbid adding new elements, as described in the next section.

The 2119 words in the 4th paragraph are questionable. It's hard to put MUST level requirements on people, and the MAY is a statement of fact.

In the last two paragraphs:

Internet-Drafts are not appropriate places to document things, other than ephemerally on their ways to become RFCs. I-Ds expire. 

Saying extensions MAY be documented in RFCs doesn't add anything; anything may be documented in RFCs. I assume therefore you mean at least SHOULD. If so, what kind(s) of RFCs would be appropriate?

The suggestion that private extensions need not be documented in RFCs can be harmful to long-term interoperability. So-called private extensions have a way of migrating to public networks.

-7.2:

Wouldn't non-backward compatible extensions require a new version number? Doesn't this violate the requirements in the parent section?

-8:

I am surprised not to see registries for methods and result codes, especially with the considerable text about extensibility. Do you expect them to be extended?

10.2:
The references to 2616, 2818,  and 5246 probably need to be normative. Also, 2616 is obsolete.

Editorial and nits:
-------------------

- IDNits points out a number of citations without matching references

-1.1: VIDEO-ON-DEMAND and LIVE-STREAMING

I suggest changing "It refers to" to "VIDEO-ON-DEMAND refers to..." and "LIVE-STREAMING refers to..."

- 2.2, definition of CONNECT: "... Peer
      registers in the Tracker (or if already registered) to notify it..."

What is the antecedent of "it"? (peer or tracker?)

- 2.3.1, 4): 
s/"is responded with"/ "is responded to with" (Or even better, "The tracker responds to the request with...")

- 3.1 : "... turning the definitions for
   JSON objects extensible."

I don't understand the phrase. Do you mean "making the definitions...extensible"?

- 3.2.2, 1st paragraph:

Paragraph seems out of place, and seems redundant with the rest of the section. The placement here makes it look like NAT status selection is the primary use, and I don't think that's the intent.

s/"inform the tracker on the preferred type"/"inform the tracker of the preferred type"

- 3.2.5, first paragraph:

s/can be related with/can be related to

-3.3.4, response element:

s/ppsp_tp_interger_t/ppsp_tp_integer_t

- 4.1.1, 3rd paragraph after table 6

The first sentence is convoluted and hard to parse. I suggest breaking it into simpler sentences.


-4.1.2, 4th paragraph, "... with regard to the possibility of
   connecting with other IETF efforts such as ALTO [RFC7285]."

I don't understand the intent of this phrase.

-4.1.2, 5th paragraph:

The structure of the sentence is confusing. Do you mean to say that included elements MUST include public addresses?

-4.1.2, 3rd to last paragraph:

The paragraph seems redundant to the previous paragraph.

-6, first paragraph:

s/"impersonating to be another valid participant"/"impersonate a valid participant"

-7.2, security issues: "Being security an important component of any
      protocol..."

I don't understand this phrase.

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2015-10-14)
No email
send info
- I-D nits notes a bunch of missing reference entries, e.g.
for RFC6972 as well as 6 others. Probably some xml2rfc
issue.

- intro: last para (just before 1.1) puzzles me. Not sure
why it''s there.

- intro: why is there no mention of Bit Torrent? This seems
to be the same design for the same purpose, and BT is in
widespread use so not explaining the relationship seems a
bit odd. 5.1.2 seems to be plain silly in that light, while
BT is not a "standard" that is irrelevant - it has been
widely deploy and migration from BT to this, or
co-existence, would seem critical to the success of this
effort.

- RFC2616 is obsoleted.

- 6.1: I agree with Katheen's discuss, a MUST use TLS is
needed here really and just reflects reality and is not an
additioanl consideration. It is needed for clarity though.

- 6.2: Given the history of spoofing in BT I wondered why
there is no object level origin auth defined here. 

- I also agree with Ben's discuss.

(Brian Haberman) No Objection

Comment (2015-10-15 for -10)
No email
send info
I support the DISCUSSes raised by Barry, Ben, Kathleen, and Stephen.

(Joel Jaeggli) No Objection

Comment (2015-10-12 for -10)
No email
send info
Neville Brownlee performed the opsdir review


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

Barry Leiba (was Discuss) No Objection

Comment (2016-01-07)
No email
send info
Version -12 addresses my DISCUSS points and almost all of my comments.  Thanks very much for the work on this.

Two non-critical things remain, if you don't mind another minor update:

In Section 4, I would prefer that you add the section reference for 
Content-Type, like this:

OLD
the Content-Type field in HTTP/1.1 [RFC7231],
NEW
the Content-Type field in HTTP/1.1 (Section 3.1.1.5 of [RFC7231]),
END

But that's not critical, and the HTTP references are OK now.

I also still prefer that you change the title of Section 8.1 to "Media 
Type Registration" ... but also not critical.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-12-14 for -11)
No email
send info
1. Section 5.2.7
Please make mention and reference to security provisions for SNMP and Syslog.  RFC5424 is just for syslog, so a pointer for SNMP security considerations should be added in this section as well.  They use a boilerplate for the text and add considerations specific to a draft.   Benoit - do you have a good reference for them to use?  A more generic SNMP draft might not be up-to-date with the latest boilerplate text.  If that's the case, the recent changes are small and could be stated with a pointer to an RFC with the older boilerplate text.

- Thanks for adding an SNMP reference.  I would think there is a better, more recent one that could be used.  Moving to a comment for your AD to help you with and not hold up on this one.


2. Are there any considerations for the statistics collected, can they be used in a malicious way?  I would think so and that this would be an important security consideration.  Mentioning possible issues would be helpful to the reader.

- Thanks for adding in text about this one!

3. Section 6
Reference to RFC2616 isn't enough for the security considerations of HTTP since that's a really old RFC.  If you want authentication options, you could point to the HTTPAuth documents, which include updated versions of HTTP basic (RFC7616) and digest (RFC7617).  While there are still lots of security issues with these options, the RFCs spell out what the actual considerations are, which are helpful to the reader.  This raises the need for TLS 1.2 as well to provide session protection for the session (passive and active attacks) as well as for the authentication used.

You mention HTTPAuth's digest in 6.1, but there's no reference.  This is a little better, so I am moving this to a comment from discuss.

4. Section 6.1
Why isn't TLS a must here to protect the session data?
If you are relying on OAuth Bearer tokens, they offer no security protection without TLS, so to rely on this, I'd say TLS really should be a MUST.  The authentication types to get a bearer token (at least in RFC documentation and in the registry) are all pretty weak and require TLS protection to have any level of security.

With the TLS MUST, we are recommending TLS 1.2 as the minimum in drafts.  It would be good to see a mention of TLS 1.2 as a minimum recommendation and a reference to the BCP for TLS 1.2 configurations RFC7525 (it even includes cipher suite recommendations).

- Thanks for adding in the MUST for TLS and the reference to RFC7525.

5. Privacy
I would have expected some discussion on the protection of the 2 ID types and the tracker capabilities and that session encryption (TLS) ought to be used when this is a consideration.  Is there a reason this isn't covered?  If it's not a concern, I'd like to understand why.

-Thanks for adding in a privacy section!

Alvaro Retana No Objection