Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastructure, May 28, 2008
RFC 5594

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

(Jari Arkko) Yes

Comment (2009-05-07)
No email
send info
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.

(Cullen Jennings) Yes

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Pasi Eronen) No Objection

Comment (2009-05-06)
No email
send info
Typo in appendix B: s/Eric Pescorla/Eric Rescorla/

(Adrian Farrel) No Objection

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

Comment (2009-05-06)
No email
send info
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

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

Comment (2009-05-05)
No email
send info
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).