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

["Ben Campbell" <[e-mail]>]

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.

>>
>>
>> ----------------------------------------------------------------------
>> 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?

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

[...]

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

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.

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

[...]

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

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

[...]

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

[...]

>>
>> -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?

>
>>
>> - 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?

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

>> -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?

[...]

>>
>> -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..."?

[...]

>>
>> -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? 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..."


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

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

[...]

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

[...]