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

Changed document authors from "Rui Cruz, Mario Nunes, Jinwei Xia, Joao Taveira, Gu Yingjie, Deng Lingli, Rachel Huang" to "Rui Cruz, Mario Nunes, Jinwei Xia, Joao Taveira, Deng Lingli, Rachel Huang"

[Ballot comment]
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.

[Ballot comment]
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!

[Ballot comment]
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.

[Ballot discuss]
You use RFC 2616 as a reference for HTTP 1.1, but that's obsolete, and the current reference should be RFC 7230 for the general references and RFC 7231, Section 3.1.1.5 for Content-Type (the citation in Section 4 here).  The Security Considerations section should cite both 7230 and 7231.

-- Section 3.1 --

  A JSON object consists of name/value pairs.  The JSON names of the
  pairs are indicated with "".

I don't find the meaning of the second sentence to understandable at all.  What are you trying to say?

-- Subsections of 3.2 --
Where are the semantics of the string values, such as "HIGH", "NORMAL", and "LOW", defined?

-- Section 4 --

  For deployment scenarios where Peer (Client) authentication is
  desired at the Tracker, HTTP Digest Authentication MUST be supported,
  with TLS Client Authentication as the preferred mechanism, if
  available.

You need a normative reference to RFC 7616 for HTTP Digest Authentication, and a citation here.

-- Section 4.1.1.1 --
Please re-check your examples carefully, and pass them through a JSON validator.  In the first example, for instance, the Content-Length value is wrong and the "transaction_id" member is missing its ":".  The third example uses "TransactionID" instead of "transaction_id" for the member name.

Be careful during AUTH48 that you re-check this, including making sure that any Content-Length values are still correct after all the editing.

[Ballot comment]
Is the definition give for "LEECH" sufficient?:

  LEECH:  A Peer that has not yet completed the transfer of all Chunks
  of the media content.

I don't think "completed the transfer" is clear enough, and "transfer" can be outbound or inbound.  Would something like "A Peer that has not yet received all chunks of the media content, and therefore can't be used to share the content," be better?  And isn't it possible for a peer to share the chunks that it has, even if it doesn't have all of the chunks?

You do seem inconsistent with capitalization of terms ("SEEDER" and "Seeder", "LEECH" and "Leech", "SWARM and "Swarm" and "swarm").  You should fix that -- readers often find it confusing, and the RFC Editor will ask you about it during AUTH48.

-- Section 1.2.1 --
I don't understand the meaning of "[Peer Protocol]" in front of list items 3, 4, and 5.  Why's it there?  And if you're going to leave it there, I think you might do better to find notation that doesn't look like how we write reference citations.

-- Section 2.2 --

  Requests are sent, and responses returned to these requests.  A
  single request generates a single response (neglecting fragmentation
  of messages in transport).

The word "neglecting" can make this ambiguous -- it can be taken to mean that fragmentation can't happen.  It might be better to say it this way:

NEW
  Requests are sent, and responses returned to these requests.  A
  single request generates a single response (though both requests
  and responses can be subject to fragmentation of messages in
  transport).
END

-- Section 4.3 --

  If the peer fails to read the tracker response, the same Request with
  identical content, including the same transaction_id, SHOULD be
  repeated, if the condition is transient.

...and...

  The tracker SHOULD be prepared to receive a Request with a repeated
  transaction_id.

Given the first paragraph, why isn't the SHOULD in the second one a MUST?

In the list of error responses, why are some of them MUST and others SHOULD?

-- Section 4.4 --
There are no JSON things called "fields".  Objects have "members" and arrays have "elements".  I think you mean to use "members" in this section.

-- Section 7 --

  Additionally, a designer MUST remember that extensions themselves MAY
  also be extensible.

The "MAY" shouldn't be a 2119 key word, and should be changed to lower case.

-- Section 8.1 --
This is not defining a registry; it's making a registration in the media types registry.  We no longer use the term "MIME type", so please change the title to "Media type registration", and change the first paragraph:

OLD
  This document defines registry for application/ppsp-tracker+json
  media types.
NEW
  This document registers the application/ppsp-tracker+json
  media type.
END

You also use "MIME type" in the "File extension" information (you can actually just change that to "n/a").  And you haven't updated the registration template to the latest one specified in RFC 6838 -- there's a new "Fragment identifier considerations" item (which can just be "n/a" also, but please add it).

-- Section 10 --
Some of your informative references are for required functions, and should be normative.  In particular, RFC 2616 needs to be changed to 7230 and 7231 (see above) and needs to be normative.  2818 and 5246 should be normative.  3986 and 5952 tell you how to encode IP addresses, and should be normative.

[Ballot discuss]

6.2 - can you explain to me how the overall protection
against pollution works? I'm not quite following it and am
concerned that it may be lacking. But that may just be me
forgetting how this ties together with rfc7574.

[Ballot comment]
- 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.

[Ballot discuss]
I think this draft needs privacy considerations. The protocol carries sensitive information in the form of IP addresses and location. If I understand correctly it may also identify transferred content, which can be highly sensitive under some circumstances. Encryption is optional.  It think it needs stronger guidance on privacy implications and the use of HTTPS.

[Ballot discuss]
I think this draft needs privacy considerations. The protocol sensitive information in the form of IP addresses and location. If I understand correctly it may also identify transferred content, which can be highly sensitive under some circumstances. Encryption is optional.  It think it needs stronger guidance on privacy implications and the use of HTTPS.

[Ballot comment]
- 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.

[Ballot discuss]
Thanks for your work on this draft, I have a few things I'd like to discuss that we should be able to resolve quickly.  I'll try where possible to offer suggestions, but please do let me know if there is a good reason why they don't make sense.

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.

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.

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.

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).

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.

[Ballot comment]
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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ppsp-base-tracker-protocol-10. If any part of this review is inaccurate, please let us know.

IANA has questions about the actions requested by this document.

IANA believes that this document is requesting two actions, but it may be asking for a third.

First, IANA will register the following media type at http://www.iana.org/assignments/media-types, using the template provided in Section 8.1:

application/ppsp-tracker+json  [RFC-ietf-ppsp-base-tracker-protocol-10]

QUESTION: The first sentence of Section 8.1 says, "This document defines registry for application/ppsp-tracker+json media types."

Should "registry" be replaced with "registration"? Or is this sentence referring to the registry in Section 8.2? If neither of these, this section is missing registry creation instructions.

Second, IANA will create the following registry at a location to be determined:

Registry Name: PPSP Tracker Protocol Version Number Registry
Registration Procedure: ?
Reference: this document

ppsp_tp_version_t  Description    Reference
----------------------------------------------------------+
0                |  Reserved                            |  this document
1                |  Protocol specified in this document |  this document
2-255        |  Unassigned

QUESTION: What's the registration procedure for this registry? For examples, see Section 4.1 of RFC 5226.

QUESTIONS FOR THE CHAIRS: Should this registry be placed at http://www.iana.org/assignments/ppspp?

If not, 1) should the registry be created at a new URL, and 2) would an existing category at http://www.iana.org/protocols be appropriate, or should we create a new one?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)) to Proposed Standard


The IESG has received a request from the Peer to Peer Streaming Protocol
WG (ppsp) to consider the following document:
- 'PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-10-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.  The PPSP Tracker Protocol enables cooperating peers to
  form content streaming overlay networks to support near real-time
  Structured Media content delivery (audio, video, associated timed
  text and metadata), such as adaptive multi-rate, layered (scalable)
  and multi-view (3D) videos, in live, time-shifted and on-demand
  modes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document describes protocol specification. So it is Proposed Standard, as indicated in the front page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the Peer-to-Peer Streaming Protocol Tracker Protocol (PPSP-TP), 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.  The PPSP-TP enables cooperating peers to form content streaming overlay networks to support near real-time Structured Media content delivery (audio, video, associated timed text and metadata).

Working Group Summary

There was debate on the encoding of the protocol messages, particularly on text-based versus binary-based. Rough consensus was finally made that using text-based encoding as mandatory encoding scheme.

Document Quality

There is at least one implementation of PPSP-TP, as described in another PPSP Usage I-D. The document itself should have good quality, based on several rounds of expertise review conducted within PPSP group.

Personnel

Document shepherd is Ning Zong. Responsible AD is Martin Stiemerling

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document should be ready for publication, after several rounds of expertise review conducted within PPSP group.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Some JSON encoding examples may need broader review from JSON experts.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No IPR disclosure yet.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure yet.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

WG consensus represents a strong agreement among a few individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Checked, and no error found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No such review required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No such normative reference.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No such normative reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

New registry for media type in HTTP/1.1 header is proposed, as part of PPSP-TP encoding scheme.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document describes protocol specification. So it is Proposed Standard, as indicated in the front page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document specifies the Peer-to-Peer Streaming Protocol Tracker Protocol (PPSP-TP), 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.  The PPSP-TP enables cooperating peers to form content streaming overlay networks to support near real-time Structured Media content delivery (audio, video, associated timed text and metadata).

Working Group Summary

There was debate on the encoding of the protocol messages, particularly on text-based versus binary-based. Rough consensus was finally made that using text-based encoding as mandatory encoding scheme.

Document Quality

There is at least one implementation of PPSP-TP, as described in another PPSP Usage I-D. The document itself should have good quality, based on several rounds of expertise review conducted within PPSP group.

Personnel

Document shepherd is Ning Zong. Responsible AD is Martin Stiemerling

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document should be ready for publication, after several rounds of expertise review conducted within PPSP group.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No concern.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Some JSON encoding examples may need broader review from JSON experts.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No IPR disclosure yet.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR disclosure yet.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

WG consensus represents a strong agreement among a few individuals.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Checked, and no error found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No such review required.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No such normative reference.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No such normative reference.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No change to existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

New registry for media type in HTTP/1.1 header is proposed, as part of PPSP-TP encoding scheme.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.