Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
draft-p2pi-cooper-workshop-report-01

[Ballot comment]
Good that we get the report out. This seminar was one of the most
useful additional events organized by IETF, it clearly had an impact.

A couple of comments on the draft, however:

I felt that it would have been useful to make a bolder statement
in Section 2 about this problem being restricted to P2P. The
general issue is: if end users are migrating (for whatever reason
and for whatever application) to more "always on" type of traffic,
this has a fundamental impact on whether statistical multiplexing
is a viable form of building networks in the future. At the end of
the day, you have to give customers what they want (for a reasonable
price to you and them), not try to block them from doing, say,
24x7 surveillance apps, P2P, or IPTV.

IMHO, Section 4 does not give full justice to what Stanislav was speaking
about. It paints the issue in terms of damaging neighbours, when Stanislav
was saying that its even in the best interest of the P2P applications
to behave nicely, because they may hurt even the person running them,
if you are behind the congested DSL modem/router in your home and both
the P2P and web apps suffer from the latency.

The appendix on agenda should probably list the speaker's names, too.

Given the nature of unstable URLs, I think it would be useful to list the titles of the position papers in the RFC itself.

[Ballot comment]
The header says "Intended status: Standards Track". I don't believe this is correct.

5.1.3.  Multi-Layer Tracker-Based Architecture

[...]

  Inasmuch as the multi-layer scheme might require ISPs to aid peers in

s/Inasmuch/In as much

  finding the optimal paths to unauthorized copies of copyrighted
  content, ISPs may be concerned about the legal liability of
  participating.

[Ballot comment]
Appendix D references a page on the tools wiki. Once this draft is published we should consider marking that page somehow to remind future maintainers that an RFC points to it (so they would know to perhaps submit an errata if the page had to be moved away for instance).