Re: [ppsp] Ben Campbell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Ben,

Please see further late replies inline^^. Thank you for your comments.

BR,
Rachel


> -----Original Message-----
> From: Ben Campbell [mailto:[e-mail]]
> Sent: Saturday, November 14, 2015 6:55 AM
> To: Huangyihong (Rachel)
> Cc: The IESG; [e-mail];
> [e-mail]; Zongning; [e-mail]
> Subject: Re: Ben Campbell's Discuss on
> draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)
> 
> On 26 Oct 2015, at 21:58, Huangyihong (Rachel) wrote:
> 
> > Hi Ben,
> >
> > Thank you for the detailed comments. We're so sorry for the late
> > replies. Please see them inline.
> 
> Well, my reply is late, too :-) Comments inline. I removed sections that do not
> seem to need further discussion.
> 
> >
> > BR,
> > Rachel
> >
> >
> >> -----Original Message-----
> >> From: Ben Campbell [mailto:[e-mail]]
> 
> [...]
> 
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> 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.
> >
> > [Rachel]: How about adding a privacy subsection in Section 6 as
> > following?
> >
> > NEW
> > "
> > Section 6.5  Privacy for Peers
> >
> > The PPSP-TP provides mechanisms in which the peers can send message
> > containing IP addresses, ports and other information to the tracker. A
> > tracker or a third party who is able to intercept such messages can
> > store and process the obtained information in order to analyze peers'
> > behaviors and communication patterns. Such analysis can lead to
> > privacy risks. For example, an unauthorized party may snoops on the
> > data transmission from the peer to a tracker in order to introduce
> > some corrupted chunks.
> >
> > The PPSP peer protocol [RFC7574] has already included some mechanisms
> > to protect the streamed content, see section 12.3 and 12.4 of
> > [RFC7574]. For PPSP-TP, peer implementations as well as tracker
> > implementations MUST support the "https" URI scheme [RFC2818] and
> > Transport Layer Security (TLS) [RFC5246]. In addition, a peer should
> > be cognizant about potential tracker tracking through queries of
> > peers, e.g., by using HTTP cookies. The PPSP-TP protocol specified in
> > this document does not rely on HTTP cookies. Thus, peers MAY decide
> > not to return cookies received from the tracker, in order to making
> > some additional tracking more difficult.
> > "
> >
> 
> That helps, thanks. I will clear my discuss on the assumption that this text will
> go into the draft.

[Rachel]: I will submit a new version to address this and other comments.

> 
> >>
> >>
> >> ---------------------------------------------------------------------
> >> -
> >> 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.
> >
> > [Rachel]: Maybe I should check all the descriptions in the document. A
> > LEECH is a peer which hasn't finished downloading the whole content
> > yet, but it is also contributes its downloaded content with other
> > LEECH. A SEEDER is a peer which has the whole content. It just
> > contributes the content to others, and it does not download.
> 
> Those are the definitions that don't seem to fit the usage in the rest of the
> document. It's possible I misunderstand things, but I gather that a peer
> declares it's intent to be a leech or a seeder when it when it joins a swarm.
> How does that make sense if the definition of leech and seed is based entirely
> on the transient state of whether a peer has finished downloading the content?

[Rachel]: Your point makes sense to me. How about the following changes for definitions

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

SEEDER:  A Peer that holds and shares the complete media content.
"

NEW
"
LEECH: A LEECH refers to the peers in a swarm that download content from other peers as well as contribute its downloaded content with others. A LEECH SHOULD join the swarm with uncompleted media content.

SEEDER: A SEEDER refers to the peers in a swarm that only contribute the content they have to others. A SEEDER SHOULD join the swarm with the complete media content. 
"

> 
> >
> >>
> >> - 1.1, LIVE STREAMING:
> >>
> >> Is there an expectation of syncing reception between receivers?
> >
> > [Rachel]: For live streaming, receivers are all receiving the same
> > content. The out of sync is caused by different network transmission
> > time. So the lag is quite small, and usually does no harm to
> > individual user's watching experience. So currently, it is not widely
> > considered in streaming protocols.
> 
> I'm okay with the answer of "no, it is not expected", or "no, it is out of scope"
> but I don't agree that out-of-sync reception never harms the viewing
> experience. But is reasonable to say that PPSP-TP is not designed for
> applications where in-sync reception is needed. (I think it would help to include
> words to that effect.)

[Rachel]: Good suggestion. I'll include this sentence in the next version.

> 
> [...]
> 
> >>
> >> - 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.
> >>
> >
> > [Rachel]: Currently , a management of a distributed tracker is out of
> > scope of this document. The tracker in this document is treated as a
> > single logical entity. Maybe we should add clarification words in this
> > part.
> 
> I think some clarification is needed. The current text suggests that ppsp-tp, as
> written, applies equally to distributed trackers. But I think you are saying that it
> does not. That is, some aspects of the protocol may be useable for both
> monolithic and distributed trackers, but there may be some requirements for
> distributed trackers that are not covered.

[Rachel]: That's not what I mean. The PPSP-TP is both applicable for monolithic and distributed trackers. The difference is that in distributed tracker cases, we need some additional management methods to choose a tracker for specific peers. And there may be some communications requirements between different trackers if they are serving for the same media content. But this part should not be considered in PPSP-TP because PPSP-TP is a protocol for communication between tracker and peers. 

> 
> I say that assuming that a distributed tracker might require ppsp-tp
> connections to more than one instance at a time. If, on the other hand, the fact
> that a tracker is distributed or not is hidden behind a single connection, then I
> can see how it wouldn't matter if the tracker was distributed.

[Rachel]: For a peer, it doesn't have to know if the tracker is distributed or not. It doesn't matter.

> 
> >
> >> - 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?
> >
> > [Rachel]: Please see the definition of PEER ID in Section 1.1
> > terminology part. It is quoted as following
> >
> > "
> > PEER ID:  The identifier of a Peer such that other Peers, or the
> > Tracker, can refer to the Peer by using its ID.  The Peer ID is
> > mandatory, can take the form of a universal unique identifier (UUID),
> > defined in [RFC4122], and can be bound to a network address of the
> > Peer, i.e., an IP address, or a uniform resource identifier/locator
> > (URI/URL) that uniquely identifies the corresponding Peer in the
> > network.  The Peer ID and any required security certificates are
> > obtained from an offline enrollment server.
> > "
> >
> 
> I grant that. But 1.2.2 says "the specification of the format of the peer-ID is not
> in the scope of this document." Now, that may be strictly true if you want to
> say it must be unique, but don't care how that uniqueness is represented. But if
> so, I think a clarification in 1.2.2 would help.

[Rachel]: All right. A clarification in 1.2.2 will be presented in the next version.

> 
> [...]
> 
> >
> >>
> >> - 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?
> >
> > [Rachel]: How about deleting this paragraph?
> 
> Wouldn't that lose the part about a single request generating a single
> response?
> 
> How about "Peers send requests to tracker. Trackers send a single response for
> each request."

[Rachel]: Oh, you mean it should be stating as an active voice. Good suggestion.

> 
> >
> >>
> >> - Figure 5: Is there a matching peer state machine (i.e. that models
> >> the internal state of a peer?)
> >
> > [Rachel]: No, peer doesn't have to keep a state machine. It's all in
> > the server side.
> >
> >>
> 
> [...]
> 
> >
> >>
> >> -2.3.2: "Peers MUST NOT generate protocol elements that are invalid."
> >>
> >> That's an odd use of "MUST NOT".
> >
> > [Rachel]: How about changing to "SHOULD NOT".
> 
> That would then be an odd use of "SHOULD NOT" :-)  Seriously, though, I
> should have been more clear in my comment. It doesn't make sense to use a
> 2119 keyword to effectively say that implementors must not violate the
> protocol. That's about the same thing as saying you MUST follow the other
> MUSTS.

[Rachel]: Got your point. How about changing to "are required to"?

> 
> [...]
> 
> >> -3.3.4:
> 
> [...]
> 
> >
> >>
> >> "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?
> >
> > [Rachel]: Sorry for causing the confusion. It's the result of a
> > request from the peer to the tracker. It includes the information that
> > the tracker responds to the request.
> 
> So would it make sense to say "A swarm action result element contains the
> result of an action requested by the peer.?

[Rachel]: Way better. Apologize for our bad English:(.

> 
> [...]
> 
> >>
> >> -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?
> >
> > [Rachel]: It is optional because they are not mandated conditions for
> > a tracker to search for a peer list. It is possible that the tracker
> > in a implementation may never require these elements. But in some
> > implementations, the tracker may have some filter algorithms for
> > searching peers. Thus, the peers in those implementations can include
> > corresponding attributes in the request, so that the tracker can
> > manage the information of all peers, and search for appropriate set of
> > peers for a requesting peer.
> 
> Is it safe to say that the peer can include these things or not, and the tracker
> might or might not do something with them if they are present--but that the
> tracker would never require them for basic operation?

[Rachel]: Yes.

> 
> >
> >>
> >> - 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?
> >
> > [Rachel]: Yes. So it's better to change to "SHOULD"?
> 
> A couple of thoughts here: Does it ever make sense to _not_ do this if the
> authorization info is present?

[Rachel]:considering security, implementations is recommend to do peer authentications. However, whether the implementations do it or not does not affect the PPSP-TP.

> 
> If the answer is NO, then this might should be formulated as a MUST. But on
> the other hand, it would be perfectly find to simply say "The tracker starts by
> preprocessing..."

[Rachel]: So I think just simply to say "The tracker starts by preprocessing...".

> 
> >> -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".
> >
> > [Rachel]: Here we mean that the tracker is also a STUN server. As you
> > said the tracker can perform STUN-like function by putting peer's
> > address it observes in the response. Will add some clarifications to
> > help reader to understand this.
> 
> Is it actually a STUN server, or a "STUN-like" server? Is there text somewhere
> that says a tracker can be a STUN server?

[Rachel]: Sorry. I should have clarified it more clearly. A tracker works as a "STUN-like" server. How about the following change?

OLD
"
   If STUN-like function is enabled in the tracker,
   the peer_addr includes the attribute type with a value of REFLEXIVE,
   corresponding to the transport address "candidate" of the peer.
"
NEW
"
  Peers can use Session Traversal Utilities for NAT (STUN) [RFC5389] and Traversal Using Relays around NAT (TURN) [rfc5766] to gather their candidates. If no STUN is used and the tracker is able to work as a "STUN-like" server which can inspect the public address of a peer, the tracker can return the address back with a " REFLEXIVE " attribute type.
"

> 
> [...]
> 
> >>
> >> -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?
> >
> > [Rachel]: Yes. It is assumed that some invalid response types are
> > appeared.
> 
> Would it make sense to say "If the peer receives an invalid response..."?

[Rachel]: Yes. Better.

> 
> [...]
> 
> >>
> >> -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?
> >
> > [Rachel]: The integrity verification schemes mentioned in Section 6.2
> > are considered in peer protocol, which can reference section 6.1 of
> > RFC7574.
> >
> 
> Does RFC 7574 already require integrity checks?

[Rachel]: Yes, it does.

> If so, then the MUST here is
> not needed; it would be better to state the requirement descriptively. (e.g.
> "RFC 7574 requires the use of..."

[Rachel]: Good suggestion. Will do.
> 
> 
> >> -7:
> 
> [...]
> 
> >> 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?
> >
> > [Rachel]: These should be proposed standard RFCs.
> 
> So would it make sense to say "Extensions MUST be documented in
> standards-track RFCs if
>     there are requirements for coordination, interoperability, and broad
>     distribution."

[Rachel]: Yes. Thanks for the suggestion.
> 
> >> 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.
> >
> > [Rachel]: So maybe we should delete the last paragraph.
> 
> That works for me.
> 
> >
> >>
> >> -7.2:
> >>
> >> Wouldn't non-backward compatible extensions require a new version
> >> number?
> >> Doesn't this violate the requirements in the parent section?
> >
> > [Rachel]: Maybe rewording is needed here. How about changing to the
> > following?
> > OLD
> > "
> > -  Backward Compatibility:  One of the most important issues to
> >    consider is whether the new extension is backward compatible with
> >    the base PPST-TP.
> > "
> >
> > NEW
> > "
> > -  Backward Compatibility: The new extension MUST be backward
> > compatible with the base PPSP-TP specified in this document.
> > "
> 
> That works for me.
> 
> 
> >>
> >> -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?
> 
> I did not see a response to this question.

[Rachel]: Sorry, this one must have been omitted. Yes, the methods and result codes can be probably extended in the future. I'll will add registries for these two fields.

> 
> [...]
> 
> >
> >>
> >> Editorial and nits:
> >> -------------------
> >>
> 
> [...]
> 
> >> - 4.1.1, 3rd paragraph after table 6
> >>
> >> The first sentence is convoluted and hard to parse. I suggest
> >> breaking it into simpler sentences.
> >
> > [Rachel]: Sure. How about the following change
> >
> > OLD
> > "
> > The element peer_num indicates to the tracker the number of peers to
> > be returned in a list corresponding to the indicated properties, being
> > ability_nat for NAT traversal (considering that PPSP-ICE NAT traversal
> > techniques may be used), and optionally concurrent_links, online_time
> > and upload_bandwidth_level for the preferred capabilities.
> > "
> >
> > NEW
> > "
> > The element peer_num indicates the maximum number of peers to be
> > returned in a list from the tracker. The returned peer list can be
> > optionally filtered by some indicated properties, such as ability_nat
> > for NAT traversal, and concurrent_links, online_time and
> > upload_bandwidth_level for the preferred capabilities.
> > "
> 
> That helps, thanks!
> 
> >
> >>
> >>
> >> -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.
> >
> > [Rachel]: How about changing it as to the following:
> > OLD
> > "
> > The tracker may take network location information into consideration
> > as well, to express network topology preferences or Operators' policy
> > preferences, with regard to the possibility of connecting with other
> > IETF efforts such as ALTO [RFC7285].
> > "
> >
> > NEW
> > "
> > The tracker may take network location information into consideration
> > as well, to express network topology preferences or operators' policy
> > preferences. It can implement other IETF efforts like ALTO[RFC7285],
> > which is out of the scope of this document.
> > "
> 
> That helps, thanks.
> 
> [...]